7장. 가치 있는 단위 테스트를 위한 리팩터링
좋은 단위 테스트 스위트의 속성
- 개발 주기에 통합돼 있다
- 코드베이스 중 가장 중요한 부분만을 대상으로 한다
- 최소한의 유지비로 최대의 가치를 끌어낸다
- 가치 있는 테스트
- 가치 있는 테스트 작성하기
리팩터링할 코드 식별하기
코드의 네 가지 유형
- 복잡도 또는 도메인 유의성
- 코드 복잡도는 코드 내 의사 결정 지점 수로 정의한다
- 도메인 유의성은 코드가 프로젝트의 문제 도메인에 대해 얼마나 의미 있는지를 나타낸다
- 클래스 또는 매서드가 가진 협력자 수
- 가변 의존성이거나 프로젝트 외부 의존성 이다
- 협력자가 많은 코드는 테스트 비용이 많이 든다
기초가 되는 4가지 유형
- 도메인 모델과 알고리즘
- 간단한 코드
- 컨트롤러
- 지나치게 복잡한 코드
코드가 더 중요해지거나 복잡해질수록 협력자는 더 적어야 된다
좋지 않은 테스트를 작성하는 것보다는 테스트를 전혀 작성하지 않는 편이 낫다
험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기
지나치게 복잡한 코드를 쪼개려면, 험블 객체 패턴을 써야 한다
헥사고날과 함수형 아키텍처는 험블 객체 패턴을 사용한다
험블객체 패턴을 보는 또 다른 방법은 단일 책임 원칙(SRP)을 지키는 것
또 다른 예로 도메인 주도 설계에 나오는 집계 패턴이 있다
최적의 단위 테스트 커버리지 분석
비지니스 로직과 오케스트레이션을 완전히 분리하면 코드베이스의 어느 부분을 테스트할수 있다
전제 조건을 테스트해야 하는가?
전제 조건에 도메인 의미가 없으면 테스트는 가치가 없다
컨트롤러에서 조건부 로직 처리
비지니스 로직과 오케스트레이션의 분리
- 저장소에서 데이터 검색
- 비즈니스 로직 실행
- 데이터를 다시 저장소에 저장
결론
추상화할 것을 테스트하기보다 추상화를 테스트하는 것이 더 쉽다