테스트 주도 개발
철학
핵심 원칙: 테스트는 내부 구현 세부 사항이 아닌 공개 인터페이스를 통해 동작을 검증해야 합니다. 코드는 완전히 바뀔 수 있지만, 테스트는 바뀌지 않아야 합니다.
좋은 테스트는 통합 스타일입니다. 즉, 공개 API를 통해 실제 코드 경로를 실행합니다. 테스트는 시스템이 어떻게 하는지가 아니라 무엇을 하는지 설명합니다. 좋은 테스트는 명세처럼 읽힙니다. "사용자가 유효한 장바구니로 결제할 수 있음"은 정확히 어떤 기능이 존재하는지 알려줍니다. 이러한 테스트는 내부 구조를 신경 쓰지 않기 때문에 리팩터링에도 견딥니다.
잘못된 테스트는 구현에 결합되어 있습니다. 내부 협력 객체를 모의(mock)하고, 비공개 메서드를 테스트하거나, 외부 수단(인터페이스를 사용하는 대신 데이터베이스에 직접 쿼리하는 등)을 통해 검증합니다. 경고 신호: 동작은 변경되지 않았는데 리팩터링할 때 테스트가 실패합니다. 내부 함수 이름을 바꿨을 때 테스트가 실패한다면, 그 테스트는 동작이 아닌 구현을 테스트한 것입니다.
예제는 tests.md를, 모의 가이드라인은 mocking.md를 참조하세요.
안티 패턴: 수평적 슬라이싱
모든 테스트를 먼저 작성하고, 모든 구현을 나중에 작성하지 마십시오. 이것은 "수평적 슬라이싱"입니다. 즉, RED 단계를 "모든 테스트 작성"으로, GREEN 단계를 "모든 코드 작성"으로 취급하는 것입니다.
이는 형편없는 테스트를 만들어냅니다:
- 일괄 작성된 테스트는 실제 동작이 아닌 상상된 동작을 테스트합니다.
- 사용자 대면 동작보다는 사물의 형태(데이터 구조, 함수 시그니처)를 테스트하게 됩니다.
- 테스트가 실제 변경에 둔감해집니다. 동작이 중단되어도 통과하고, 동작이 정상이어도 실패합니다.
- 전조등 너머로 달려나가며, 구현을 이해하기 전에 테스트 구조에 얽매이게 됩니다.
올바른 접근 방식: 추적 탄환을 통한 수직적 슬라이스. 하나의 테스트 → 하나의 구현 → 반복. 각 테스트는 이전 주기에서 배운 내용에 응답합니다. 방금 코드를 작성했기 때문에 어떤 동작이 중요하고 어떻게 검증할지 정확히 알 수 있습니다.
잘못된 예 (수평):
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. 계획
코드베이스를 탐색할 때 CONTEXT.md(있는 경우)를 읽어서 테스트 이름과 인터페이스 어휘가 프로젝트의 도메인 언어와 일치하도록 하고, 수정하는 영역의 ADR을 존중하세요.
코드를 작성하기 전에:
- 필요한 인터페이스 변경 사항을 사용자와 확인
- 테스트할 동작의 우선순위를 사용자와 확인
- 깊은 모듈(작은 인터페이스, 깊은 구현)의 기회 식별 — 어휘와 테스트 가능성 검사를 위해
/codebase-design스킬 실행 - 테스트할 동작 목록 작성 (구현 단계 아님)
- 계획에 대한 사용자 승인 받기
질문: "공개 인터페이스는 어떻게 되어야 합니까? 어떤 동작이 가장 중요합니까?"
모든 것을 테스트할 수는 없습니다. 정확히 어떤 동작이 가장 중요한지 사용자와 확인하세요. 가능한 모든 가장자리 케이스가 아니라 중요한 경로와 복잡한 로직에 테스트 노력을 집중하세요.
2. 추적 탄환
시스템에 대한 한 가지를 확인하는 테스트를 하나 작성하세요:
RED: 첫 번째 동작에 대한 테스트 작성 → 테스트 실패
GREEN: 통과시키기 위한 최소 코드 작성 → 테스트 통과
이것이 추적 탄환입니다. 전체 경로가 끝까지 작동함을 증명합니다.
3. 점진적 루프
나머지 각 동작에 대해:
RED: 다음 테스트 작성 → 실패
GREEN: 통과시키기 위한 최소 코드 → 통과
규칙:
- 한 번에 하나의 테스트
- 현재 테스트를 통과시키기에 충분한 코드만
- 미래의 테스트를 예측하지 말 것
- 테스트는 관찰 가능한 동작에 집중
4. 리팩터링
모든 테스트가 통과한 후 리팩터링 후보를 찾으세요:
- 중복 추출
- 모듈 심화 (단순한 인터페이스 뒤에 복잡성 이동)
- 자연스러운 곳에 SOLID 원칙 적용
- 새 코드가 기존 코드에 대해 무엇을 드러내는지 고려
- 각 리팩터링 단계 후 테스트 실행
RED 상태에서는 절대 리팩터링하지 마세요. 먼저 GREEN에 도달하세요.
주기별 체크리스트
[ ] 테스트는 구현이 아닌 동작을 설명하는가
[ ] 테스트는 공개 인터페이스만 사용하는가
[ ] 테스트는 내부 리팩터링에도 견딜 수 있는가
[ ] 코드는 이 테스트에 최소한인가
[ ] 추측성 기능이 추가되지 않았는가