1/13 TIL 목 처리

• 시스템 끝 (비관리 의존성과 직접 통신하는 부분) 을 목으로 처리하자.
  • 중간 단계에 실제 객체가 많을수록 테스트가 견고해진다.
  • 리팩터링 내성 향상, 회귀 방지
  • 그렇다고 중요하지 않은 부분까지 모두 시스템 끝에서 처리할 필요는 없다. (로깅의 구조 확인 등)
• 스파이 (직접 작성한 목). 시스템 끝에서는 스파이가 목보다 낫다.
  • 검증 단계 코드 재사용이 가능하다.
  • 가독성이 개선된다.
  • 라이브러리가 제공하는 Mock도 결국 제품 코드다. 완전히 믿을 수 없다. 믿을 수 있는 건 직접 작성한 테스트코드 뿐
• 단위 테스트에서는 목 안 쓴다!
• 테스트에 사용된 목의 수는 상관 없다.  - 한 동작 단위에서 얼마든지 많아질 수 있고, 이는 통제 범위 밖이다.
• 목의 호출을 체크하자 (원하는 게 호출 됐는지,  쓸데 없이 추가 호출 됐는지)
• 보유 타입만 목으로 처리하자
  • 서드 파티의 인터페이스를 사용하지 말자 - 이해하기도 어렵고, 언제 바뀔지 모른다.
  • 대신 서드파티의 어댑터를 작성해서 어댑터를 목으로 처리하자

추가 개념

플루언트 인터페이스

메서드 체이닝을 기반으로 코드가 쉬운 영어 문장으로 보이게끔 가독성을 향상시키는 API 설계 기법

내 생각

시스템의 끝단만 목으로 처리한다는 개념이 고전파 테스트의 진수처럼 보인다. 끝과 끝만 테스트하면 중간의 변화로 인한 거짓 양성이 자연스럽게 줄어든다.

참고

단위 테스트

플루언트 인터페이스