테스트는 문서이기도 하다. 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완한다.
어느 한 사람이 과거에 경험했던 고민의 결과물을 테스트를 녹여낸다. 이 테스트를 팀 차원으로 승격시켜 모두의 자원으로 사용할 수 있다.
DisplayName을 섬세하게
@DisplayName("음료 1개를 추가하면 주문 목록에 담긴다.")
- 명사의 나열보다 문장으로 작성
- a이면 b이다
- a이면 b가 아니고 c다.
- ~ 테스트 (X)
- 테스트 행위의 결과까지 기술하기
- 음료 1개를 추가할 수 있다. (X)
- 음료1개를 추가하면 주문 목록에 담긴다. (O)
- 도메인 용어를 사용하여 한층 추상화된 내용을 담기
- 특정 시간 이전에 주문을 생성하면 실패한다. (X)
- 영업 시작 시간 이전에는 주문을 생성할 수 없다.(o)
- 테스트 현상을 중점으로 기술하지 말 것 (성공, 실패)
- 실패한다 (X)
- 생성할 수 없다.(o)
BDD 스타일로 작성하기 (Behavior Driven Development)
- TDD에서 파생된 개발 방법
- 함수 단위의 테스트에 집중하기보다 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트 한다
- 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준(레벨)을 권장
Given : 시나리오 진행에 필요한 모든 준비 과정(객체, 값, 상태 등)
When : 시나리오 행동 진행
Then : 시나리오 진행에 대한 결과 명시, 검증
** 언어가 사고를 제한한다.
한번 언어로 규정해 놓은 것에 갇히면 우리의 사고도 갇혀버린다. 우리가 잘못 작성한 테스트는 나중에 우리의 사고를 제한하고 발목을 잡을 수 있다. ** 문서로써의 테스트가 중요하다
참고 및 출처 : https://www.inflearn.com/course/practical-testing-실용적인-테스트-가이드/dashboard
'TDD' 카테고리의 다른 글
Presentation Layer의 테스트 (0) | 2024.11.24 |
---|---|
레이어드 아키텍처(Layered Architecture) 와 테스트 (0) | 2024.11.18 |
TDD가 정확히 무엇일까? (0) | 2024.11.11 |
단위테스트(Unit test) (1) | 2024.11.10 |
테스트는 왜 필요할까? (0) | 2024.11.09 |