[xUnit 테스트 패턴] 12장 - 테스트 조직하기
12장 - 테스트 조직하기
개요
- 테스트 메소드
- 테스트 구성에 따라 테스트를 찾고 이해하기 쉽게 유지할 수 있는지 여부가 결정 됨
적당한 크기의 테스트 메소드
- 테스트별 하나의 조건만 검증
- 반복되는 테스트 가능
- SUT의 동작이 변경됐을 때 고쳐야 하는 테스트의 수를 줄일 수 있다.
테스트 메소드와 테스트케이스 클래스
클래스별 테스트케이스 클래스
- 처음에는 하나의 테스트케이스 클래스에 테스트 메소드를 전부 작성
- 테스트 케이스 클래스가 커지면 클래스를 더 쪼개야 한다.
기능별 테스트케이스 클래스
- SUT의 특정 기능 검증에 관련된 모든 테스트 메소드를 하나의 테스트케이스 클래스에 작성
- 장점 : 기능과 관련된 모든 테스트 조건을 보기 쉬워짐
- 단점 : 테스트케이스 클래스에 비슷한 픽스처 설치 코드가 필요할 수 있음
픽스처별 테스트케이스 클래스
- 테스트 픽스처를 필요로 하는 모든 테스트 메소드를 픽스처별 테스트케이스 클래스에 몰아 넣음
- 기능별 테스트케이스 클래스의 반대 개념
- 장점 : 테스트 픽스처 설치 코드를 setUp 메소드에 둘 수 있음
- 단점 : 기능별로 테스트 조건이 여러 테스트케이스 클래스에 흩어질 수 있음
테스트 메소드 조직 전략 선택하기
- 픽스처별 테스트케이스 클래스
- 상태가 다양한 객체에 대해 단위 테스트를 작성해야 하고 그 객체의 상태별로 테스트 메소드들을 테스트 해야 할 때
- 기능별 테스트케이스 클래스
- 고객이 인지할 수 있는 기능별로 모든 테스트를 한곳에 모아 사용 할 때
- 테스트별로 약간씩 다른 픽스처가 필요하면
픽스처별 테스트케이스 클래스 패턴을 선택하고 위임 설치로 픽스처 설치를 쉽게 해주는 것이 정답
테스트 이름 규약
- SUT 클래스 이름
- 실행하려는 메소드나 기능의 이름
- SUT 실행과 관련된 입력 값의 중요 특징
- SUT나 SUT 의존 객체의 상태에 관련된 것
- 테스트 메소드 이름 명명 규칙 - should
- SUT가 실행될 때 기대하는 출력(응답)
- SUT를 실행한 후 SUT와 그 의존 객체들의 기대 상태 값
- ex) testApprove_shouldEndUpInScheduledState()
- ex) testApprove_shouldThrowInvalidRequestEx()
테스트 스위트 조작하기
- 테스트 스위트 팩토리 -> 테스트 스위트 객체 생성 -> 테스트케이스 객체 -> 테스트 메소드 실행
테스트 집단 실행하기
- 테스트 스위트 - 테스트 그룹
- 테스트 패키지별로 AllTests라는 테스트 스위트 팩토리를 만든다.
- 부분 스위트 - 같이 실행하고 싶은 테스트들만 이름 있는 테스트 스위트로 만들 수 있다.
- ex) 데이터베이스 없이 실행할 수 있는 테스트들
하나의 테스트 실행하기
- 단일 테스트 스위트
- 테스트 스위트 계층도에서 원하는 테스트만 하나 선택해서 실행
테스트 코드 재사용
- 재사용으로 인해
문서로서의 테스트 라는 가치와 타협하면 안된다!!
테스트 유틸리티 메소드 위치
- 테스트 패키지별로 테스트 클래스의 의존 비순환(타입이나 클래스에 직접적으로 의존해서는 안된다) 상태가 유지되게 테스트케이스 상위클래스를 생성 할 수 있다.
- 도메인 패키지별로 테스트 도우미를 하나씩 생성한 후 적당한 테스트 패키지에 다양한 테스트 도우미들을 두는 것
테스트케이스 상속과 재사용
- 테스트 유틸리티 메소드를 쓰기 위해서 사용
이런 경우는 거의 없다.
테스트 파일 구성
- 테스트 로직을 제폼 코드에 넣지 않으면서도 각 코드나 기능에 테스트를 찾을 수 있는게 핵심
내장 자체 테스트
- 테스트가 제품 코드에 같이 들어있어 언제든지 실행 가능
- 추천하지 않음
테스트 패키지
테스트 의존
- 제품 코드 내 테스트 의존을 전부 제거 했다는 걸 확인해야 함