[Good Code Bad Code] 단위테스트의 실제-2

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.353~361)를 읽고 정리한 글입니다.

 

테스트만을 위해 퍼블릭으로 만들지 말라

프라이빗 함수 중 일부를 테스트 코드에서도 접근할 수 있도록 만들어 직접 테스트하고자 할 수 있다. 하지만 이렇게 된다면 두 가지 문제점이 발생할 수 있는데 첫 번째로 구현 세부 사항과 밀접하게 연관된 테스트가 될 수 있고 실제적으로 테스트해야 하는 코드의 동작을 테스트하지 않을 수 있다.

 

프라이빗 함수를 테스트하는 것은 바람직하지 않을 때가 많다.

class MortgageAssessor{
    
    // public API
    MortgageDecision assess(Customer customer){ 
    	if(!isEligibleForMortgage(customer){
        	return MortgageDecision.rejected();
        }
        return MortgageDecision.approve();
    } 
    
    //** private 헬퍼 함수 → 테스트를 위해서만 공개 **/
	static Boolean isEligibleForMortgage(Customer customer){
    	return customer.hasGoodCreditRating() &&
        	!customer.hasExistingMortgage() &&
            !customer.isBanned();
    } 
}

 

MortgageAssessor 클래스에서 고객의 신용등급이 나쁜 경우 대출 신청이 거부되는지를 테스트해야 한다. 그러나 isEligibleForMortgage() 함수를 프라이빗에서 퍼블릭으로 변경하여 테스트하면, 우리가 실제로 확인하고자 하는 행동을 정확히 검증하지 못할 가능성이 있다. isEligibleForMortgage 함수 테스트는 실제로 우리가 신경 쓰는 행동을 테스트하는 것이 아니다. 위에서 말한 것과 같이 고객의 신용등급이 나쁘면 주택 담보 대출 신청이 거절되는 것이 우리가 신경 써야 하는 결과다. 해당 함수 테스트가 통과했다고 해도 주택 담보 대출 신청이 궁극적으로 거부된다는 것이 이 테스트로 인해 보장되지 않는다.

 

이렇게 하면 테스트가 구현 세부 사항에 종속되며, 이상적으로는 리팩터링 후에도 테스트가 실패하지 않아야 한다. 그러나 구현 함수를 직접 테스트하면 리팩터링으로 인해 테스트가 실패할 가능성이 생긴다.

 

좋은 단위 테스트는 궁극적으로 중요한 행동을 테스트해야 한다. 이렇게 한다면 

• 코드의 문제점을 정확하게 감지할 가능성이 극대화
• 구현 세부사항에 독립적

으로 된다.

 

해결책 : 퍼블릭 API를 통해 테스트 하라 

비교적 간단한 클래스의 경우 퍼블릭 API만을 사용하여 모든 동작을 테스트하기가 매우 쉽다. 

 

해결책 : 코드를 더 작은 단위로 분할하라 

 

만약 클래스가 더 복잡하거나 많은 논리를 포함하면 퍼블릭 API를 통해 모든 동작을 테스트하는 것이 까다로울 수 있다. 이 경우는 추상화 계층이 너무 크다는 것을 의미하기 때문에 코드를 더 작은 단위로 분할하는 것이 유익하다.

 

코드를 테스트하기 위해 프라이빗 함수를 퍼블릭으로 만든다면, 이것은 실제로 신경 써야 하는 행동을 테스트하지 않는다는 경고 신호로 받아들여야 한다.

---