Test-Driven Development
출력 언어
기본적으로 사용자와 소통할 때는 간체 중국어를 사용하며, 테스트 전략, 테스트 설명 및 구현 요약도 간체 중국어로 작성합니다. 사용자가 명시적으로 다른 언어를 지정하거나 기존 문서 언어가 다른 규칙을 따르는 경우 해당 규칙을 따릅니다. 코드, 명령어, 제품명 및 원문을 유지해야 하는 인용문은 강제로 번역하지 않습니다.
Philosophy
핵심 원칙: 테스트는 퍼블릭 인터페이스를 통해 동작(behavior)을 검증해야 하며, 구현 세부사항을 검증해서는 안 됩니다. 코드가 완전히 바뀌더라도 테스트는 바뀌지 않아야 합니다.
좋은 테스트는 통합 스타일입니다. 퍼블릭 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을 존중합니다.
코드를 작성하기 전에:
- 필요한 인터페이스 변경 사항을 사용자와 확인
- 테스트할 동작의 우선순위를 사용자와 확인
- 인터페이스 경계가 불분명할 때 코드베이스 설계 원칙을 사용해 깊은 모듈(deep module) 기회 파악. 사용자가 명시적으로 요청하지 않는 한 다른 스킬을 자동으로 호출하지 않음.
- 테스트할 동작 나열 (구현 단계가 아님)
- 계획에 대한 사용자 승인 받기
질문: "퍼블릭 인터페이스는 어떻게 생겼나요? 어떤 동작을 가장 중요하게 테스트해야 할까요?"
모든 것을 테스트할 수는 없습니다. 사용자와 정확히 어떤 동작이 가장 중요한지 확인하세요. 모든 가능한 엣지 케이스가 아니라 중요한 경로와 복잡한 로직에 테스트 노력을 집중하세요.
2. 트레이서 불릿
시스템에 대한 한 가지를 확인하는 테스트를 하나 작성합니다:
RED: 첫 번째 동작에 대한 테스트 작성 → 테스트 실패
GREEN: 통과할 수 있는 최소 코드 작성 → 테스트 통과
이것이 트레이서 불릿입니다. 경로가 처음부터 끝까지 작동함을 증명합니다.
3. 점진적 루프
나머지 각 동작에 대해:
RED: 다음 테스트 작성 → 실패
GREEN: 통과할 수 있는 최소 코드 작성 → 통과
규칙:
- 한 번에 하나의 테스트
- 현재 테스트를 통과할 수 있는 충분한 코드만
- 미래의 테스트를 예측하지 않음
- 테스트는 관찰 가능한 동작에 집중
4. 리팩터링
모든 테스트가 통과한 후 리팩터링 후보를 찾습니다:
- 중복 추출
- 모듈 심화 (간단한 인터페이스 뒤로 복잡성 이동)
- 자연스러운 SOLID 원칙 적용
- 새 코드가 기존 코드에 대해 무엇을 드러내는지 고려
- 각 리팩터링 단계 후 테스트 실행
RED 상태에서는 절대 리팩터링하지 마세요. 먼저 GREEN에 도달하세요.
사이클별 체크리스트
[ ] 테스트는 동작을 설명하고, 구현을 설명하지 않음
[ ] 테스트는 퍼블릭 인터페이스만 사용
[ ] 테스트는 내부 리팩터링에도 살아남음
[ ] 코드는 이 테스트에 필요한 최소한
[ ] 추측성 기능 추가 안 함