11장 - 단위 테스트 안티 패턴

11장에서 다루는 내용

비공개 메서드 단위 테스트

단위 테스트를 하기 위한 비공개 메서드 노출

테스트로 유출된 도메인 지식

구체 클래스 목 정리

 

비공개 메서드를 테스트해야 하는가?

이 질문은 자주 받는 질문이며 짧게 대답하면 하지 말아야 합니다.

테스트의 원칙 중 하나인 식별할 수 있는 동작만 테스트해야 합니다.

비공개 메서드를 테스트하는 것은 구현 세부사항과 결합되고 리팩터링 내성이 떨어지게 됩니다.

따라서 직접 테스트하지 않고 간접적으로 테스트하는 것이 좋습니다.

 

비공개 메서드가 덩치가 너무 커진 경우는 오히려 추상화를 통해 별도의 클래스를 추출해야 할 수 있습니다.

 

물론 정말 정말 특별한 경우라면 리플랙션을 통해 테스트할 수 있다.

책에서는 ORM에서 비공개 생성자를 이용하지만 중요한 로직이라 테스트해야 하는 경우를 예시로 듭니다.

 

비공개 상태 노출

단위 테스트의 목적으로는 private -> public으로 바꾸는 것은 안티 패턴입니다.

해당 필드가 변하는 것을 직접 테스트하지 말고, 그 변경으로 인해 식별할 수 있는 동작을 테스트하면 됩니다.

예를 들어 할인을 받을 수 있는지 없는지 private인 status를 테스트하지 않습니다.

다만  해당상태를 기반으로 할인율이 잘 반영되는지를 테스트하면 됩니다.

 

테스트로 유출된 도메인 지식

예를 들어 value1, value2를 더하는 계산기의 add 메서드를 테스트한다고 가정합니다.

이때 expected필드를 계산할 때 value1 + value2를 통해 구해냅니다.

이제 검증로직에서 add의 result와 expected가 동일한지 검사합니다.

 

이런 테스트는 제품 코드에서 알고리즘 구현을 단순 복사하여 기댓값을 만들었습니다.

즉, 구현 세부 사항과 결합되어 리팩터링 내성 지표에서 거의 0점을 받게 됩니다.

 

오히려 도메인 전문가의 도움을 받아 하드코딩된 값을 기댓값으로 쓰는 것이 좋습니다.

우리가 의아할 수 있는 이유 중 하나로 모든 독자는 숫자 두 개를 더하는 데 있어서는 전문가입니다.

 

 

코드 오염

예를 들어 테스트 환경임을 나타내는 매개변수인 flag를 제품코드에 녹일 수 있습니다.

하지만 테스트코드와 제품코드를 잘 분리해야 합니다.

 

오히려 테스트를 진행할 때 상황에 따라 외부호출을 하는 의존성이 존재하여 flag로 분리하내만 테스트가 가능하다면

내부의 테스트하기 어려운 험블 객체를 외부로 분리해 내고 그 후에 Mock을 활용하는 식으로 대응할 수 있습니다.