코드를 리팩터링하지 않고서는 테스트 스위트를 크게 개선할 수 없습니다. 먼저 리팩터링의 방향을 설명하고자 코드를 네 가지 유형으로 분류하는 방법을 소개합니다.
모든 프로덕션 코드는 2차원으로 분류할 수 있습니다.
코드의 복잡도는 코드 내 분기 지점 수로 정의합니다. 이 숫자가 클수록 복잡도는 더 높아집니다.
도메인 유의성은 코드가 프로젝트의 문제 도메인에 대해 얼마나 의미있는지를 나타냅니다. 일반적으로 도메인 계층의 모든 코드는 최종 사용자의 목표와 직접적인 연관성이 있으므로 도메인 유의성이 높습니다. 반면, 유틸리티 코드는 이런 연관성이 없습니다.
복잡하고 도메인 유의성을 가진 코드는 회귀 방지에 뛰어나기 때문에, 단위 테스트에서 가장 이롭다고 할 수 있습니다. 복잡함과 도메인 유의성은 독립적인데, 예를 들어 주문 가격을 계산하는 메서드에 조건문이 없다면 순환 복잡도는 1이지만 비지니스에 중요한 기능이므로 테스트하는 것이 중요하다고 할 수 있습니다.
두 번째 차원은 클래스 또는 메서드가 가진 협력자 수입니다. 협력자가 많은 코드는 테스트 비용이 많이 들기에, 협력자의 유형이나 수를 잘 고려해야 합니다.
위 그림은 네 가지 코드 유형에 관한 그림입니다.
도메인 모델 및 알고리즘을 단위 테스트하면 노력 대비 가장 이롭습니다. 해당 코드가 복잡하거나 중요한 로직을 수행해서 테스트의 회귀 방지가 향상되기 때문에 가치있다고 할 수 있습니다.
가장 문제가 되는 코드는 지나치게 복잡한 코드인데, 이는 알고리즘과 컨트롤러라는 두 부분으로 나누는 것이 일반적입니다.
지나치게 복잡한 코드를 피하고 도메인 모델과 알고리즘만 단위 테스트하는 것이 매우 가치 있고 유지 보수가 쉬운 테스트 스위트로 가는 길이지만 각각의 테스트가 프로젝트 가치를 높이는 테스트 스위트를 목표로 해야 합니다.