[Test] 테스트는 '문서'다.

테스트는 [ 문서 ]다.

테스트 코드를 단순히 프로덕션 코드를 검증하는 도구라고만 생각하면, 그 가치의 절반밖에 보지 못하는 것이다. 나는 테스트 코드가 곧 '살아있는 문서'라고 생각한다.

테스트가 왜 문서가 될까?

생각해보자. 우리는 항상 팀으로 일한다. 내가 짠 코드를 언젠가 다른 동료가 봐야 하고, 내가 과거에 했던 고민을 그 동료가 또 똑같이 할 필요는 없다.

바로 이때 테스트 코드가 빛을 발한다.

• 다양한 테스트 케이스는 프로덕션 코드의 기능과 정책을 설명하는 가장 정확한 설명서가 된다.
• 과거에 누군가 했던 고민의 결과물을 팀의 자산으로 만들어준다.
• 새로운 팀원이 들어왔을 때, 테스트 코드를 통해 시스템의 동작 방식을 빠르게 이해할 수 있다.

결국 잘 짜인 테스트는 동료를 위한 가장 친절한 가이드가 된다.

좋은 문서 만들기: DisplayName을 섬세하게

그렇다면 어떻게 테스트를 '좋은 문서'로 만들 수 있을까? 가장 쉽고 강력한 방법은 테스트 이름을 잘 짓는 것이다. JUnit5의 @DisplayName을 적극적으로 활용하자.

• '~ 테스트' 같은 명사 나열은 피하고, 'A이면 B이다' 형태의 문장으로 작성하자.
  • 음료 1개 추가 테스트 (X)
  • 음료를 1개 추가하면 주문 목록에 담긴다. (O)
• 메서드 이름이 아닌, 도메인 정책과 비즈니스 관점에서 서술하자.
  • 특정 시간 이전에 주문하면 실패한다. (△)
  • 영업 시작 시간 이전에는 주문을 생성할 수 없다. (O)

테스트의 현상(성공, 실패)이 아닌, '그래서 어떤 행동이 어떤 결과를 낳는가'에 집중하는 것이 핵심이다.

BDD 스타일로 명확성 더하기

테스트를 시나리오 관점에서 작성하면 훨씬 이해하기 쉬운 '문서'가 된다. 이때 BDD(Behavior Driven Development) 스타일을 차용하면 큰 도움이 된다.

BDD는 TDD에서 파생된 방법론으로, 함수 단위의 테스트보다 시나리오 자체에 집중한다. 코드를 잘 모르는 사람이 봐도 이해할 수 있을 정도의 가독성을 추구한다. 핵심 구조는 다음과 같다.

• Given (주어진 상황): 시나리오 진행에 필요한 모든 준비 과정.
• When (행동): 시나리오의 핵심이 되는 행동.
• Then (결과): 행동에 따른 결과와 검증.

이 구조는 테스트의 의도를 명확히 드러내 주고, 위에서 말한 '좋은 DisplayName'을 작성하는 데 훌륭한 가이드가 되어준다.

import static org.assertj.core.api.Assertions.assertThat;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

class CafeKioskTest {

    @Test
    @DisplayName("음료를 1개 추가하면 주문 목록에 담긴다.")
    void add() {
        // given
        CafeKiosk cafeKiosk = new CafeKiosk();
        Americano americano = new Americano();

        // when
        cafeKiosk.add(americano);

        // then
        assertThat(cafeKiosk.getBeverages()).hasSize(1);
        assertThat(cafeKiosk.getBeverages().getFirst().getName()).isEqualTo("아메리카노");
    }
}

@DisplayName과 Given-When-Then 주석만으로도 이 테스트가 무엇을 검증하는지 한눈에 파악할 수 있다. 이것이 바로 '테스트로 말하는 문서'다.

---

Ref) Practical Testing: 실용적인 테스트 가이드 강의 | 박우빈 - 인프런