Part III 프로세스
CHAPTER 12 단위 테스트
- 작은 테스트는 빠르고 결정적이어서 개발자들이 수시로 수행하며 피드백을 즉각 얻을수 있다
- 단위 테스트는 대체로 대상 코드와 동시에 작성할 수 있을 만큼 작성하기 쉽다
- 빠르게 작성할 수 있으므로 테스트 커버리지를 높이기 좋다
- 시스템의 특정 부분에 집중하므로 실패 시 원인을 파악하기 쉽다
- 대상 시스템의 사용법과 의도한 동작 방식을 알려주는 문서자료 혹은 예제 코드 역활을 한다
유지보수하기 쉬워야 한다
- 변경과 상관없는 변경 때문에 실패하는 깨지기 쉬운 테스트들이 도사리고 있다
- 무엇이 잘못되어 실패했는지 어떻게 고쳐야 하는지를 파악하기 어려운 불명확한 테스트들이다
깨지기 쉬운 테스트 예방하기
깨지기 쉬운 테스트 란? : 실제로는 버그가 없으에도 심지어 검증 대상 코드와는 관련조차 없는 변경 때문에 실패하는 테스트를 말한다
- 변하지 않는 테스트를 만들기 위해 노력하자
- 순수 리팩터링
- 새로운 기능추가
- 버그 수정
- 행위 변경
- 공개 API를 이용해 테스트하자
- 상호작용이 아닌 상태를 테스트하자
명확한 테스트 작성하기
명확한 테스트라 함은 존재 이유와 실패 원인을 엔지니어가 곧바로 알아차릴 수 있는 테스트를 말한다
- 완전하고 간결하게 만들자
- 완전한 테스트 : 결과에 도달하기까지의 논리를 읽는 이가 이해하는 데 필요한 모든 정보를 본문에 담고 있는 테스트
- 간결한 테스트 : 관련 없는 정보는 포함하지 않는 테스트
- 메서드가 아니라 행위를 테스트하자
- 테스트의 구조는 행위가 부각되도록 구성
- 테스트 이름은 검사하는 행위에 어울리게 짓자
- 테스트에 논리를 넣지 말자
- 실패 메시지를 명확하게 작성하자
테스트와 코드 공유: DRY가 아니라 DAMP!
대부분의 소프트웨어는 반복하지 말라는 DRY(Don’t Repeat Yourself) 원칙을 따른다
DAMP(descriptive and meaningful phrases) : 서술적이고 의미 있는 문구
DAMP가 DRY를 대체하지 않는다 보완 해주는 개념이다
- 공유 값
- 공유 셋업
- 공유 도우미 메서드와 공유 검증 메서드
- 테스트 인프라 정의하기