[Test Code / Java] @DisplayName과 BDD

테스트는 []다.

테스트란 문서라고 할 수 있다.

• 테스트 코드는 프로덕션 기능을 설명하는 문서가 될 수 있다.
• 다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완할 수 있다.
• 어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격시켜서, 모두의 자산으로 공유할 수 있다.

---

DisplayName

@DisplayName은 Junit5부터 시작된 어노테이션이다.

테스트 메서드 이름만으로는 이 테스트가 어떤 테스트인지 알아보기 어려울 수 있다.

이때 @DisplayName 어노테이션을 통해 테스트에 대한 좀 더 상세한 설명을 적을 수 있다.

또한 인텔리제이에서 작업할 때 @DisplayName을 사용하면 유용한 점이 하나 더 있다.

인텔리제이의 Settings > Build, Execution, Deployment > Build Tools > Gradle로 가서

위 사진처럼 Run tests using을 인텔리제이로 바꾸고 테스트를 돌리면 DisplayName을 더 잘 활용할 수 있다.

 

 

바꾸기 전에는 테스트 결과가 아래 사진처럼 표시되지만,

 

 

바꾼 뒤 돌리면, 좌측에 저렇게 DisplayName에 적어준 내용이 표시돼서 어떤 테스트가 성공했고, 실패했는지 더 파악하기 쉽다.

---

DisplayName의 내용을 적을 때

문장형으로 적기

테스트의 이름은 명사의 나열보다는 문장형으로 지어주는 것이 좋다.

예를 들면

• 음료 총합 계산 테스트 → X
• 아메리카노 1개, 라떼 1개의 총액은 8500원이다.

 

테스트 행위에 대한 결과까지 적어주기

예를 들면 아래의 문장보다

• 음료를 한 개 추가할 수 있다.

테스트의 결과까지 담긴 아래의 문장이 더 좋은 이름이다.

• 음료를 한 개 추가하면 주문 목록에 담긴다.

 

⭐️도메인 용어를 사용하여 한층 더 추상화 된 내용 담기

예를 들면 아래 문장보다

• 특정 시간 이전에 주문을 생성하면 실패한다.

아래 문장이 더 좋은 이름이다.

• 영업 시간 이전에는 주문을 생성할 수 없다.

두 문장의 다른 점은 “영업 시간”이라는 서비스의 도메인 용어를 사용하여 테스트 이름을 지었다는 것이다.

“특정 시간”이라는 단어는 카페 키오스크라는 도메인에서만 쓰이는 단어가 아니라 더 범용적으로 쓰이는 단어이다. 그런 범용적 단어보다는 좀 더 팀원 전체가 공유하고 있는 용어인 도메인 용어를 사용하는 것이 좋다.

또 위의 예시에서 한가지 포인트를 더 볼 수 있는데, 위의 이름은 테스트의 현상(=실패 하는 상황)을 나타내고 있다.

이런 테스트의 현상과 관련한 단어를 사용하지 말고, 아래 예시처럼 테스트 하려는 상황에 대해 표현하는 이름을 짓는 것이 좋다.

---

BDD(Behavior Driven Development)

• TDD에서 파생된 개발 방법론이다.
• 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 테스트 케이스에 집중하여 테스트를 작성하는 방식이다.
• 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 레벨을 권장한다.

Given / When / Then

• Given: 시나리오 진행에 필요한 모든 준비 과정을 의미(ex. 객체, 값, 상태 등등)
• When: 시나리오 행동 진행
• Then: 시나리오 진행에 대한 결과 명시, 검증

좀 더 직관적으로 말을 바꿔보면

• Given: 어떤 환경에서
• When: 어떤 행동을 했을 때
• Then: 어떤 변화가 일어난다.

given, when, then에 맞춰 테스트 코드를 작성하면 DisplayName의 내용도 더 정확하게 작성할 수 있다.

기존에 작성한 주문 상품의 총액을 계산하는 메서드를 given, when, then으로 나눠보면 아래와 같다.

---

 

Reference

인프런 Practical Testing: 실용적인 테스트 가이드