테스트 주도 개발이 만드는 살아있는 문서
문서화의 딜레마
전통적인 문서화는 항상 두 가지 문제에 직면한다:
- 작성 비용: 문서를 작성하는 시간이 개발 시간을 잡아먹는다.
- 유지보수 비용: 코드가 변경되면 문서도 업데이트해야 하지만, 현실에서는 문서가 먼저 낡아간다.
핵심 통찰
테스트는 실행 가능한 명세서
TDD의 테스트는 단순한 검증 코드가 아니다. 이는 시스템의 동작을 정확히 기술하는 실행 가능한 명세서다.
- 전통적 문서: “이 함수는 두 수를 더한다” (정적, 낡을 수 있음)
- TDD 테스트:
assertEqual(add(2, 3), 5)(동적, 항상 최신)
문서화의 역설
TDD는 문서를 따로 작성하지 않지만, 가장 정확한 문서를 만든다. 테스트는 코드와 함께 유지보수되므로, 항상 현재 시스템의 상태를 정확히 반영한다.
숨겨진 가치: 온보딩 도구
새로운 팀원이 프로젝트에 합류했을 때, TDD로 작성된 테스트 스위트는 최고의 온보딩 자료다:
- 테스트를 읽으면 시스템의 동작을 이해할 수 있다.
- 테스트를 실행하면 시스템이 정상 동작하는지 확인할 수 있다.
- 테스트를 수정하면서 시스템을 변경하는 방법을 배울 수 있다.
개인적 경험
필자가 TDD를 도입한 프로젝트에서, 6개월 후에도 새로운 기능을 추가할 때 테스트가 명확한 가이드 역할을 했다. “이 테스트가 통과하면 된다”는 확신이 개발 속도를 2배 이상 높였다.