가치 있는 단위 테스트를 위한 리팩터링

모든 코드를 테스트할 필요는 없어. 비즈니스 가치가 높은 코드에 집중해야 해. 어디에 집중해야 하는지를 체계적으로 알려주는 게 7장이야.

저자는 코드를 두 축으로 분류해. 복잡도(비즈니스 로직의 양)와 협력 객체 수야. 이 두 축으로 사분면을 만들면 네 종류가 나와. 도메인 모델/알고리즘은 복잡도가 높고 협력 객체가 적어. 테스트 ROI가 제일 높은 곳이야. 의존성이 없으니까 출력 기반 테스트로 쓸 수 있거든. 컨트롤러는 복잡도가 낮고 협력 객체가 많아. 여러 컴포넌트를 연결하는 역할만 하고 복잡한 로직은 없지. 통합 테스트로 검증하면 돼. 사소한 코드는 복잡도도 낮고 협력 객체도 적어. 테스트 안 해도 돼. 지나치게 복잡한 코드는 복잡도도 높고 협력 객체도 많아. 이게 있으면 리팩토링이 필요하다는 신호야. 도메인 로직과 오케스트레이션 로직이 뒤섞인 상태거든.

테스트하기 어려운 코드를 다룰 때는 Humble Object 패턴을 써. 테스트하기 어려운 부분과 쉬운 부분을 분리하는 거야. UI 코드에서 뷰와 로직을 분리하는 게 대표적인 예야. 로직은 순수하게 만들어서 테스트하고, 뷰는 최소한으로만 남기는 거지. DB와 상호작용하는 코드도 마찬가지야. 실제 DB 접근은 레포지토리로 분리하고, 비즈니스 로직은 레포지토리 없이 독립적으로 테스트해.

저자는 고객 관리 시스템 예제로 이 과정을 보여줘. UserController에 비즈니스 로직, DB 접근, 오케스트레이션이 다 섞여 있던 걸 리팩토링해서, 도메인 로직은 User 엔티티로, DB 접근은 UserRepository로 분리해. 결과적으로 User의 비즈니스 규칙은 출력 기반 테스트로, 전체 플로우는 통합 테스트로 검증할 수 있게 돼. "지나치게 복잡한 코드" 사분면에 있던 게 "도메인 모델"과 "컨트롤러"로 분리된 거야.

---

정리

7장 읽고 기억할 거 세 가지:

1. 코드 네 사분면: 복잡도 × 협력 객체 수로 분류. 도메인 모델이 테스트 ROI 최고
2. 지나치게 복잡한 코드는 리팩토링 신호: 비즈니스 로직과 오케스트레이션이 뒤섞이면 분리해야 해
3. Humble Object 패턴: 테스트 어려운 부분을 얇게 만들고, 로직은 분리해서 순수하게 테스트해