https://blog.kingbbode.com/m/52

이 글은 .NET Core 및.NET 표준을 사용하는 단위 테스트 모범 사례라는 글에 영감을 받았습니다. 글에서 제시하는 맥락에 어느정도 동의하며 이 중 자바 관점으로의 전환이 필요한 내용과 자바 개발자 사이에서 지속적으로 발견되는 문제에 대한 경험을 종합하여 작성된 글입니다.

2021.6.15
- "9. 제어 가능한 테스트" 주의사항 보완
- "4. 테스트 구성요소의 위치" 예제 버그 수정
- "4. 테스트 구성요소의 위치" 에서 "5. 테스트 환경" 내용 분리 작성
2021.6.16
- "4. 테스트 구성요소의 위치" '도우미 메서드' 에서 "메서드 추출" 로 용어 변경

테스트는 우리가 작성한 코드가 주어진 요구사항을 해결할 수 있는지 회귀를 통하여 검증할 수 있도록 돕고, 주어진 요구사항을 테스트하므로 작성된 테스트가 문서로서 작동할 수 있으며, 의미 있는 단위의 테스트를 고민함으로써 좋은 디자인을 만드는 데에도 도움을 줍니다. 또한 테스트로 보호된 코드는 나와 동료들에게 코드의 변경을 거침없이 시도할 수 있도록 안정감과 자신감을 줍니다.

그러나 잘못 작성된 테스트는 위와 같은 테스트가 주는 장점을 수용하지 못합니다. 잘못된 테스트는 구현이 조금만 변경되어도 테스트 코드가 손상되고, 무엇을 어떻게 테스트하는지를 확인하기 위해 시간을 많이 쏟아야 하는 등 지속 가능하지 않은 코드 덩어리를 생산합니다.

이 글에서는 의미있고 지속 가능한 테스트를 만들기 위한 몇 가지 기준을 제시합니다.

1. 테스트명

테스트명은 테스트의 의도가 명확하게 드러나도록 작성합니다. 테스트의 의도는 기능적 요구사항이나 예상되는 동작을 포함합니다. (기능적 요구사항은 기획서에 표기된 요구사항이 그대로 옮겨질 수 있습니다.)

테스트 의도가 드러나지 않는 테스트명은 어떤 요구사항들이 테스트되었는지를 명확히 할 수 없으며, 모든 요구사항이 테스트되었는지 확인하기 어렵습니다. 동일한 코드라인을 사용하면서 다르게 동작할 것을 기대하는 요구사항은 충분히 발생할 수 있기 때문에 코드 커버리지로는 해소될 수 없습니다.

테스트명에 테스트의 의도를 잘 드러나면 테스트 리포트를 요구사항이 정리된 문서로 활용할 수 있으며, 테스트가 실패하였을 때 빠르게 대응할 수 있습니다.

Bad

@Test
void 숫자_한개_테스트() {
    StringCalculator stringCalculator = new StringCalculator();

    int actual = stringCalculator.add("0");

    assertThat(actual).isEqualTo(0);
}

Better

@Test
void 숫자_하나를_입력_했을_때_해당_숫자를 반환한다() {
    StringCalculator stringCalculator = new StringCalculator();

    int actual = stringCalculator.add("0");

    assertThat(actual).isEqualTo(0);
}

2. 테스트 간의 관계

테스트는 상호 독립적으로 작성합니다. 독립적으로 작성된 테스트는 요구사항에 집중하는 시각을 제공하여, 객관적이고 빠른 테스트를 할 수 있도록 합니다.