7.1 리팩터링할 코드 식별하기
7.1.1 코드의 네 가지 유형
- 도메인 모델과 알고리즘
- 간단한 코드
- 컨트롤러
- 지나치게 복잡한 코드
도메인 모델 및 알고리즘을 단위 테스트하면 노력 대비 가장 이롭다. 컨트롤러의 경우, 포괄적인 통합 테스트의 일부로서 간단히 테스트해야 한다.
코드가 더 중요해지거나 복잡해질수록 협력자는 더 적어야 한다.
지나치게 복잡한 코드를 피하고 도메인 모델과 알고리즘만 단위 테스트하는 것이 매우 가치 있고 유지 보수가 쉬운 테스트 스위트로 가는 길이다. 결국 지나치게 복잡한 코드는 도메인 모델 및 알고리즘 및 컨트롤러로 나눠서 리팩터링을 해야한다.
7.1.2 험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기
테스트 대상 코드의 로직을 테스트하려면, 테스트가 가능한 부분을 추출해야한다. 험블 객체 패턴을 사용하여 각 클래스가 하나의 단일한 책임만 가지도록 테스트하기 어려운 의존성과 비즈니스 로직을 분리시킨다. 험블 객체 패턴은 오케스트레이션을 수행하는 코드에서 복잡한 코드를 분리하도록 특별히 설계됐다.
7.2 가치 있는 단위 테스트를 위한 리팩터링하기
데이터베이스같은 외부 의존성을 사용하는 경우는 인터페이스를 두고, 이 인터페이스를 의존하는 객체에 주입한 후 테스트에서 목응로 처리한다. 하지만 결국 도메인 모델은 인터페이스를 통해 프로세스 외부 협력자에게 의존하지 않는 것이 훨씬 더 깔끔하다.
일반적으로 도메인 클래스는 다른 도메인 클래스나 단순 값과 같은 프로세스 내부 의존성에만 의존해야한다.
참고
'개발관련 서적 정리 > Unit Testing' 카테고리의 다른 글
| 8. 통합테스트를 하는 이유 (0) | 2023.02.17 |
|---|---|
| 6. 단위 테스트 스타일 (0) | 2023.02.08 |
| 5. 목과 테스트 취약성 (0) | 2023.02.06 |
| 4. 좋은 단위 테스트의 4대 요소 (0) | 2023.02.05 |
| 3. 단위 테스트 구조 (1) | 2023.02.05 |