9장 - 목 처리에 대한 모범 사례

9장에서 다루는 내용

• 목의 가치 극대화 하기
• 목을 스파이로 교체하기
• 목 처리에 대한 모범 사례

 

목은 비관리 의존성에만 적용해야 합니다.

다른 부분에 목을 적용하면 깨지기 쉬운 테스트(리팩터링 내성이 없는 테스트)가 됩니다.

목에 관해서 위의 지침만 잘 지키면 70% 이상의 성공을 거둘 수 있습니다.

 

목의 가치 극대화 하기

• 최대한 육각형 아키텍처의 바깥쪽에 있는 클래스를 모킹 하라.
• 내부의 클래스를 모킹 하는 경우에는 구현 세부 사항이 노출될 수 있기 때문이다.

 

목을 스파이로 대체하기

스파이는 수동으로 작성하는 반면에 목은 프레임워크의 도움을 받아 생성하는 것이 유일한 차이점이다.

스파이 = 실제로 개발자가 작성한 Mock

 

책에서는 Spy를 직접 인터페이스를 통해 생성하고 내부 메서드에 Assert까지 추가하여 다음과 같은 가독성을 부여한다.

busSpy.ShouldSendNumberOfMessages(1)
.WithEmailChangedMessage(user.UserId, "new@gmail.com")

이는 Mock에서 다루었던 Verify구문과 굉장히 유사해 보이지만 BusSpy는 테스트 코드에 속하며 Mock은 제품 코드에 속합니다.

테스트코드를 감시자로 생각하고, 훌륭한 감시자는 모든 것을 재확인합니다.

 

그러면 모든 목을 스파이로 대체해야 하는가?

테스트의 중요도에 따라 판단!

예를 들어 로그가 찍히는 것이 중요하지, 로그의 정확한 구조는 중요하지 않다.

 

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

서드파티 라이브러리 위에 항상 어댑터를 작성하고 기본 타입 대신 해당 어댑터를 목으로 처리하는 게 좋습니다.

• 대부분 서드파티 코드의 작동 방식에 깊이 이해하지 못한다.
• 서드파티 코드의 기술 세부 사항까지는 꼭 필요하지 않기 때문에 추상화를 통해 애플리케이션과 라이브러리의 경계를 정의
• 내장 인터페이스를 이미 제공하더라도 목으로 처리한 동작이 실제로 외부 라이브러리와 일치하는지 확인해야 하므로 해당 인터페이스를 목으로 처리하는 것은 위험하다.

 

어댑터를 코드와 외부 환경 사이의 손상 방지 계층으로 두어 다음과 같은 효과를 누립니다.

• 기본 라이브러리의 복잡성을 추상화
• 라이브러리에 필요한 기능만 노출
• 프로젝트 도메인 언어를 사용해 수행가능

세 가지 장점 모두 훌륭해 보입니다.

 

하지만 이 지침은 내부 의존성에는 적용되지 않습니다.

ex) 날짜와 시간을 제공하는 경우, ORM이 외부 애플리케이션에서 볼 수 없는 데이터베이스를 접근하는 경우

 

모든 라이브러리 위에 고유의 래퍼를 둘 순 있지만, 비관리 의존성 이외에 다른 용도로는 노력을 들일만한 가치가 없습니다.