7. 가치 있는 단위 테스트를 위한 리팩토링

리팩토링할 코드 식별하기

 

모든 제품 코드는 2차원의로 분류가 가능

• 복잡도 또는 도메인 유의성
• 협력자 수

코드 복잡도

• 코드 복잡도는 코드 내 의사 결정(분기) 지점 수가 클수록 → 복잡도 커진다.

도메인 유의성

• 코드가 프로젝트의 문제 도메인에 대해 얼마나 의미 있는지
• 일반적으로 도메인 계층(data aceess Layer)의 모든 코드는 최종 사용자의 목표가 직접적인 연관성이 있음 → 도메인 유의성이 높다
• 유틸리티 코드의 경우 연관성이 거의 없다.
• 복잡한 코드와 도메인 유의성을 갖는 코드가 단위 테스트에 가장 이롭다.
  • 회귀 방지에 뛰어나기 때문!

 

코드의 4가지 유형

 

• 도메인 모델과 알고리즘
  • 보통 복잡한 코드는 도메인 모델 but 100%는 아님
• 간단한 코드
  • 협력자가 없이 코드가 간단한 경우
  • 테스트할 가치가 0에 가깝다.
• 컨트롤러
  • 복잡하거나 비즈니스에 중요한 작업을 하는 것이 아니라 도메인 클래스와 외부 애플리케이션 같은 다른 구성 요소의 작업을 조정
• 지나치게 복잡한 코드
  • 협력자가 많고 복잡할 경우

코드의 4가지 유형의 상관관계, 지나치게 복잡한 코드는 최대한 지양해야 한다.

지나치게 복잡한 코드를 벗어나 **도메인 모델과 알고리즘만 단위 테스트하는 것**이 매우 가치는 있는 테스트임

 

험블 객체

지나치게 복잡한 코드를 쪼개려면 험블 객체 패턴를 이용해야 한다.

• 테스트 대상 코드의 로직을 테스트하려면, 테스트가 가능한 부분을 추출해야 한다.
• 결과적으로 코드는 테스트 가능한 부분을 둘러싼 얇은 험블 래퍼(humble wrapper)가 된다.
• 이 험블 래퍼가 테스트하기 어려운 의존성과 새로 유출된 구성 요소를 붙임
• 자체적인 로직이 거의 없거나 전혀 없으므로 테스트할 필요가 없음
• 단일 책임 원칙을 지키면 험블 객체 패턴을 가질 수 있음

 

참조

• 단위테스트(블라디미르 크리코프)
• https://www.kimcoder.io/books/unit-testing/7