테스트 주도 개발
철학
핵심 원칙: 테스트는 구현 세부 사항이 아닌 공개 인터페이스를 통해 동작을 검증해야 합니다. 코드는 완전히 바뀔 수 있지만 테스트는 바뀌지 않아야 합니다.
좋은 테스트는 통합 스타일입니다: 공개 API를 통해 실제 코드 경로를 실행합니다. 테스트는 시스템이 어떻게 동작하는지가 아니라 무엇을 하는지 설명합니다. 좋은 테스트는 명세서처럼 읽힙니다 — "사용자가 유효한 장바구니로 체크아웃할 수 있다"는 정확히 어떤 기능이 존재하는지 알려줍니다. 이러한 테스트는 내부 구조에 관심이 없기 때문에 리팩터링에도 살아남습니다.
나쁜 테스트는 구현에 결합되어 있습니다. 내부 협력자를 모의(mock)하고, 비공개 메서드를 테스트하거나, 외부 수단(예: 인터페이스 대신 데이터베이스를 직접 조회)으로 검증합니다. 경고 신호: 동작은 변경되지 않았는데 리팩터링할 때 테스트가 깨집니다. 내부 함수 이름을 바꿨는데 테스트가 실패한다면, 그 테스트는 동작이 아닌 구현을 테스트하고 있는 것입니다.
예제는 tests.md를, 모의(mock) 가이드라인은 mocking.md를 참조하세요.
안티 패턴: 수평적 분할
모든 테스트를 먼저 작성하고, 모든 구현을 그 다음에 작성하지 마십시오. 이것이 바로 "수평적 분할(horizontal slicing)" — RED 단계를 "모든 테스트 작성"으로, GREEN 단계를 "모든 코드 작성"으로 취급하는 것입니다.
이것은 형편없는 테스트를 만들어냅니다:
- 대량으로 작성된 테스트는 실제 동작이 아닌 상상된 동작을 테스트합니다
- 결국 사용자 대상 동작이 아닌 구조(데이터 구조, 함수 시그니처)를 테스트하게 됩니다
- 테스트는 실제 변경에 둔감해집니다 — 동작이 깨져도 통과하고, 동작이 정상이어도 실패합니다
- 자신의 헤드라이트를 벗어나 구현을 이해하기 전에 테스트 구조에 확정을 내립니다
올바른 접근 방식: 트레이서 불릿(tracer bullet)을 통한 수직적 슬라이스. 하나의 테스트 → 하나의 구현 → 반복. 각 테스트는 이전 사이클에서 학습한 내용에 응답합니다. 코드를 방금 작성했기 때문에 어떤 동작이 중요한지, 어떻게 검증할지 정확히 알 수 있습니다.
잘못된 방식 (수평):
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
올바른 방식 (수직):
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
...
워크플로우
1. 계획
코드를 작성하기 전에:
- 사용자와 어떤 인터페이스 변경이 필요한지 확인
- 사용자와 어떤 동작을 테스트할지 확인 (우선순위 지정)
- 심층 모듈(deep modules) 기회 식별 (작은 인터페이스, 깊은 구현)
- 테스트 용이성을 위한 인터페이스 설계
- 테스트할 동작 목록 작성 (구현 단계가 아님)
- 계획에 대한 사용자 승인 받기
질문: "공개 인터페이스는 어떻게 생겼나요? 어떤 동작을 가장 중요하게 테스트해야 할까요?"
모든 것을 테스트할 수는 없습니다. 사용자와 정확히 어떤 동작이 가장 중요한지 확인하세요. 모든 가능한 엣지 케이스가 아니라 중요한 경로와 복잡한 로직에 테스트 노력을 집중하세요.
2. 트레이서 불릿
시스템에 대해 하나를 확인하는 하나의 테스트를 작성하세요:
RED: 첫 번째 동작에 대한 테스트 작성 → 테스트 실패
GREEN: 통과할 최소 코드 작성 → 테스트 통과
이것이 트레이서 불릿입니다 — 경로가 종단 간 작동함을 증명합니다.
3. 점진적 루프
나머지 각 동작에 대해:
RED: 다음 테스트 작성 → 실패
GREEN: 통과할 최소 코드 작성 → 통과
규칙:
- 한 번에 하나의 테스트
- 현재 테스트를 통과할 충분한 코드만
- 미래 테스트를 예측하지 않기
- 관찰 가능한 동작에 테스트 집중
4. 리팩터
모든 테스트가 통과한 후 리팩터 후보 찾기:
- 중복 추출
- 모듈 심층화 (복잡성을 단순한 인터페이스 뒤로 이동)
- 자연스러운 곳에 SOLID 원칙 적용
- 새 코드가 기존 코드에 대해 무엇을 드러내는지 고려
- 각 리팩터 단계 후 테스트 실행
RED 상태에서는 절대 리팩터하지 마세요. 먼저 GREEN으로 가세요.
사이클별 체크리스트
[ ] 테스트가 동작을 설명하고, 구현을 설명하지 않는가
[ ] 테스트가 공개 인터페이스만 사용하는가
[ ] 테스트가 내부 리팩터 이후에도 살아남을 것인가
[ ] 이 테스트에 필요한 최소 코드인가
[ ] 추측성 기능이 추가되지 않았는가