[Practical Testing: 실용적인 테스트 가이드]
섹션 5. 테스트는 []다.
📍 개발자에게 중요한 것
- 기술에 대한 숙련도
- ❗소프트 스킬❗
ex) 커뮤니케이션 능력, 태도, 일에 임하는 몰입도, 자세, 문서 작성 능력
📌 테스트는 [문서]다.
❓ 왜?
❗ 테스트 코드는 프로덕션 기능을 설명해주는 문서가 될 수 있다.
📍 문서?
1. 프로덕션 기능을 설명하는 테스트 코드 문서
테스트 코드가 클라이언트가 돼서 프로덕션의 기능을 테스트 ➡ 테스트 코드 자체가 프로덕션 기능을 여러 케이스를 가지고 테스하기 때문에 이것 자체가 문서가 될 수 있다.
2. 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완
우리가 개발을 하거나 남들이 개발해놓은코드를 보더라고 정상 동작을 가정한 해피 케이스에만 집중을 해서 보기 때문에 예외 케이스나 다양한 엣지 케이스들을 생각하지 못함 ➡ 그런 테스트 케이스들을 통해서 프로덕션 코드를 더 깊게 그리고 다각화해서 이해할 수 있다.
3. 어느 한 사람이 과거에서 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유 가능
개발하면서 고민한 요소들을 테스트 코드에 녹여 냄 ➡ 개발에 필요한 고민과 그 고민의 결과물을 문서화 시키는 것
우리는 항상 팀으로 일한다
📌 DisplayName
테스트의 이름을 어떻게 지으면 좋을까?
테스트 하고자 하는 행위가 되는 테스트 메서드 이름을 가지고 와서 테스트의 이름으로 활용 중이었다.
하지만 메서드 명만으로는 이 테스트가 뭘 하고자 하는지/무엇을 검증하고자 하는지 표현하는 데 한계가 존재한다.
📍 DisplayName
: Junit5에서 추가된 어노테이션
@DisplayName("음료 1개 추가 테스트")
@Test
void add() {
...
}Junit4이하의 버전이라서 DisplayName 어노테이션이 지원이 안될 경우 한글 메서드명을 사용할 수 있다.
@Test
void 음료_1개_추가_테스트() {
...
}하지만 공백마다 _를 넣어줘야하는 번거로움을 감안해야한다.
📍 DisplayName을 섬세하게
처음 보는 사람도 이해할 수 있도록 명확한 제목을 짓는 것이 좋다.
1. 명사의 나열보다 문장으로 작성
ex) A이면 B다, A이면 B가 아니고 C다.
"~테스트" 지양하기.
// @DisplayName("음료 1개 추가 테스트")
@DisplayName("음료를 1개 추가할 수 있다")2. 테스트 행위에 대한 결과까지 기술
// @DisplayName("음료를 1개 추가할 수 있다")
@DisplayName("음료 1개를 추가하면 주문 목록에 담긴다.")3. 도메인 용어를 사용하여 한층 추상화된 내용 담기
메서드 자체의 관점보다 도메인 정책 관점으로 작성한다.
ex) 특정 시간 ➡ 영업 시작 시간
4. 테스트의 현상을 중점으로 기술하지 말 것
ex) 실패한다 ➡ 생성할 수 없다.
// @DisplayName("특정 시간 이전에 주문을 생성하면 실패한다")
@DisplayName("영업 시작 이전에 주문을 생성할 수 없다.")📌 BDD 스타일로 작성하기
📍 BDD, Behavior Driven Development
- TDD에서 파생된 개발 방법
- 함수 단위의 테스트에 집중하기 보다, 시나리오에 기반한 테스트케이스(TC) 자체에 집중하여 테스트한다.
- 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준(레벨)을 권장
📍 Given / When / Then
- Given : 시나리오 진행에 필요한 모든 준비 과정 (객체, 값, 상태 등)
- When : 시나리오 행동 진행
- Then : 시나리오 진행에 대한 결과 명시, 검증
어떤 환경에서(Given)
어떤 행동을 진행했을 때(When),
어떤 상태 변화가 일어난다(Then).➡ DisplayName에 명확하게 작성할 수 있다.
언어가 사고를 제한한다.
한번 언어로 규정해 놓은 것에 갇히면 우리의 사고도 그에 맞춰서 제한이 된다.
우리가 잘못 작성한(명확하지 않은) 테스트는 나중에 오히려 허들이 되고 우리의 사고를 제한하고 발목을 잡을 수 있다.
그만큼의 문서로써의 테스트가 중요하다.
📑 출처
