9. 목 처리에 대한 모범 사례

 

9.1 목의 가치를 극대화하기

 

9.1.1 시스템 끝에서 상호작용을 검증하기

 

시스템 끝에서 비관리 의존성과의 상호 작용을 검증하라.
컨트롤러와 비관리 의존성 사이의 타입 사슬에서 마지막 고리를 목으로 처리하라.
이로써 회귀 방지(통합 테스트로 검증된 코드가 더 많기 때문) 와 리팩터링 내성(코드의 구현 세부 사항에서 목을 분리하기 때문)이 향상될 수 있다.

 

9.1.2 목을 스파이로 대체하기

 

스파이는 직접 작성한 목이다.
시스템 끝에 있는 클래스에 대해서는 스파이가 목 보다 낫다.
검증 단계에서 코드를 재사용해 테스트 크기가 줄고 가독성이 개선된다.

검증문을 작성할 때 제품 코드에 의존하지 말라.

 

테스트에서 별도의 리터럴과 상수 집합을 사용하라. 필요하면 리터럴과 상수를 복제하라.
테스트는 제품 코드와 독립적으로 검사점을 제공해야 한다. 그렇지 않으면, 이름만 바꿀 뿐 동어 반복 테스트(아무것도 검증하지 않고 무의미한 검증문만 있는 테스트)를 만들 위험이 있다.

 

9.1.3 IDomainLogger는 어떤가?

 

IDomainLogger는 예제 코드에서 생성한 ILogger의 래퍼 클래스이다.

 

모든 비관리 의존성에 하위 호환성이 동일한 수준으로 필요한 것은 아니다.
메시지의 정확한 구조가 중요하지 않고 메시지의 존재 여부와 전달하는 정보만 검증하면 시스템의 끝에서 비관리 의존성과의 상호 작용을 검증하라는 지침을 무시할 수 있다.
대표적인 예가 로깅이다.

 

9.2 목 처리에 대한 모범 사례

 

목을 처리하는 것에 관련해 지금까지 두가지의 사례를 정리했다.

• 비관리 의존성에만 목 적용하기
• 시스템 끝에 있는 의존성에 대해 상호 작용 검증하기

이 장에서 알아 볼 나머지 모범 사례는 아래와 같다.

• 통합 테스트에서만 목을 사용하고 단위 테스트에서는 하지 않기
• 항상 목 호출 수 확인하기
• 보유 타입만 목으로 처리하기

 

9.2.1 목은 통합 테스트만을 위한 것

 

목은 비관리 의존성만을 위한 것이고 이러한 의존성을 처리하는 코드는 컨트롤러뿐이므로 통합 테스트에서 컨트롤러를 테스트할 때만 목을 적용해야 한다.
단위 테스트에서는 목을 사용하지 말라.

 

9.2.2 테스트당 목이 하나일 필요는 없음

 

목은 하나만 사용해야 한다는 말이 있지만, 이 것은 단위 테스트의 격리에 대한 잘못된 해석이다. 단위는 코드 단위가 아닌 동작 단위를 의미한다.
테스트에서 사용된 목의 수는 관계가 없다. 목의 수는 비관리 의존성의 수에 따라 달라진다.

 

9.2.3 호출 횟수 검증하기

 

목에 예상되는 호출이 있는지와 예상치 못한 호출이 없는지를 확인하라.

 

9.2.4 보유 타입만 목으로 처리하기

 

보유 타입만 목으로 처리하라.
비관리 의존성에 접근하는 서드파티 라이브러리 위에 어댑터를 작성하라.
기본 타입 대신 해당 어댑터를 목으로 처리하라.