[이규원의 현실 세상의 TDD: 안정감을 주는 코드 작성 방법] 2부 5장: Mockists vs Classicists

본문은 Fastcampus의 [이규원의 현실 세상의 TDD]를 수강하고 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

Sociable 테스트 vs Solitary 테스트

1) Sociable 테스트

• 시스템과 의존성(DOC)을 함께 단위 테스트하는 방식
• 즉, 시스템과 함께 의존성까지 구동시켜 테스트

 

2) Solitary 테스트

• 시스템과 의존성을 분리시켜서 단위 테스트하는 방식
• 즉, 의존성 대신 테스트 대역을 사용하여 테스트

 

 

가정의 안정도

• 테스트 대역이 늘어날수록, 테스트 대역이 구현하는 인터페이스가 복잡할수록 가정이 불안정해진다
• 테스트 대역이 줄어들수록, 테스트 대역이 구현하는 인터페이스가 단순할수록 가정이 안정된다 

 

 

Mock의 위험

• 상태검증 vs 행위 검증
  • 상태검증: 어떠한 입력에 대해 "어떠한 출력이 발생하는지" 검증
  • 행위검증: "출력을 어떻게 만드는지" 검증
  • Mock은 행위 검증에 가까움
• 정보 숨김 위배
  
  • Mock은 SUT 내부의 동작(구현)을 검증할 책임을 갖고 있다
  • 따라서 Mock을 사용해 테스트를 하게 되면 SUT 내부의 동작(구현)에 대한 정보가 테스트 코드로 노출된다
  • 따라서 테스트가 SUT 구현에 의존하게 된다
• 고통스럽고 불안한 리팩터링
  • Mock은 테스트 대상(모듈)의 내부 구현에 의존한다
  • 따라서 내부 구현을 수정하면 테스트 코드도 수정하게 된다
  • 이렇게 내부 구현에 의존하는 테스트 코드는 리팩터링을 괴롭게 만든다