TDD — 빨강·초록·리팩터의 리듬
장바구니 합계 기능을 세 사이클의 빨강(실패 테스트)→초록(최소 구현)→리팩터로 실제 진행하며, 테스트가 쌓여 안전망이 되는 과정을 실행한다.
1 / 9장바구니 합계 기능을 TDD로 만듭니다. 리듬은 셋 — 빨강(실패 테스트 먼저), 초록(통과할 만큼만 구현), 리팩터(초록을 유지한 채 정리). 테스트가 명세를 앞서 걷습니다.
빨강 — 실패 테스트초록 — 최소 구현리팩터 — 구조 개선
아직 테스트 없음
구현: 구현 없음
단계 목록 · 키보드 ←/→ 이동, Space 재생
TDD의 산출물은 테스트 파일이 아니라 두 가지다 — 테스트를 먼저 쓰느라 강제된 '테스트 가능한 설계', 그리고 초록 안전망 위에서 '언제든 고칠 수 있다는 자신감'.
왜 헷갈리는가
"코드 짜고 나서 테스트 붙이면 같은 것 아닌가"가 핵심 오해다. 사후 테스트는 지금 구현의 사본이라 구현의 버그까지 통과시키기 쉽고, 실패를 본 적이 없는 테스트는 아무것도 검증하지 않을 수 있다. 빨강을 먼저 보는 것이 '이 테스트는 진짜 잡아낸다'는 유일한 증거다.
애니메이션이 보여주는 것
return 0이라는 뻔뻔한 하드코딩이 요점이다 — '통과할 만큼만' 구현하면 다음 테스트가 그 거짓말을 잡아낸다. 이 왕복이 과설계(아직 필요 없는 일반화)를 막고, 요구를 테스트라는 실행 가능한 명세로 번역한다.
세 번째 사이클의 리팩터가 두 번째 요점이다 — 행동을 바꾸지 않고 구조만 개선하는데, 그것이 안전하다는 증거가 초록 테스트 셋이다. 리팩터링은 TDD의 보상 단계다: 안전망 없이는 도박인 일이 일상이 된다.
실무에서의 균형
교조가 아니라 도구로 쓰는 법.
- TDD가 빛나는 곳: 규칙이 복잡한 도메인 로직(가격·정산·검증), 버그 수정(재현 테스트 먼저 — 회귀 방지가 공짜), 인터페이스 설계가 불확실할 때.
- 무리한 곳: UI 픽셀, 탐색적 프로토타입, 글루 코드 — 여기선 사후 테스트나 E2E가 낫다.
- 테스트는 행동을, 구현을 아니라 — private 메서드 테스트, mock 과다는 리팩터링을 오히려 방해하는 신호.
- 리팩터 단계를 건너뛰면 TDD는 '테스트 있는 진흙'을 만든다 — 빨강·초록·리팩터는 셋이 한 리듬이다.
- 친척들: BDD(테스트 이름을 요구 언어로), 아웃사이드-인(인수 테스트에서 안으로) — 같은 원리의 방언.
기억할 것
- 빨강을 먼저 — 실패를 본 적 없는 테스트는 증거가 아니다.
- 통과할 만큼만 — 다음 테스트가 다음 요구를 강제한다(과설계 방지).
- 리팩터는 초록에서만 — 테스트가 곧 안전망이다.
- 산출물은 테스트가 아니라 '테스트 가능한 설계'와 자신감이다.