테스트는 명세다!

문제/맥락

소프트웨어 요구사항은 문서화되어도 시간이 지나면 흐려진다. 구현자와 검증자 사이에 오해가 생기고, 코드만 보고는 의도한 동작을 온전히 알기 어렵다.

테스트는 이런 간극을 메우는 방법이다. 단순한 검증 도구를 넘어서, 어떤 입력에 대해 어떤 출력이 나와야 하는지를 명확히 서술하는 살아 있는 명세가 된다.

핵심 포인트

테스트는 실행 가능한 문서다

문서는 현실과 어긋나도 아무도 알려주지 않지만, 테스트는 어긋나면 빨간불로 알려준다. 그래서 테스트로 적힌 명세는 항상 최신 상태를 유지한다.

작은 단위로 기대 동작을 기술한다

하나의 테스트는 하나의 기대만 담는다. 기대가 섞이면 실패했을 때 무엇을 고쳐야 할지 알 수 없다.

1// 수수료 계산 명세: 10만 원 이상이면 수수료 1%
2it('10만 원 이상 결제에는 1% 수수료를 부과한다', () => {
3  expect(calculateFee(100000)).toBe(1000)
4})
5
6it('10만 원 미만 결제의 수수료는 0원이다', () => {
7  expect(calculateFee(50000)).toBe(0)
8})
Copy

실패하는 테스트부터 먼저 작성한다

통과하는 테스트를 나중에 짜면, 테스트가 검증하는 게 맞는지 확신할 수 없다. 먼저 실패를 보고 시작해야 테스트 자체를 신뢰할 수 있다.

실천 방법

1. 기능을 만들기 전에 기대 동작을 문장으로 적는다.

2. 그 문장을 테스트 이름으로 옮긴다.

3. 최소한의 구현으로 테스트를 통과시킨다.

4. 리팩터링하면서 테스트가 명세로서 남아있는지 확인한다.

정리

테스트는 단순한 품질 보증 수단이 아니다. 테스트는 의도를 표현하는 실행 가능한 명세다. 명확한 테스트는 팀 간 의사소통 비용을 줄이고, 변경에 대한 신뢰를 높인다. 작은 예제로부터 시작해 테스트를 문서화 수단으로 활용하라.