테스트 주도 개발 (Test-Driven Development)
TDD는 레드 → 그린 루프입니다. 이 스킬은 그 루프가 가치 있는 테스트를 만들어내도록 하는 참조 자료입니다: 좋은 테스트가 무엇인지, 테스트를 어디에 둘지, 안티패턴, 그리고 루프의 규칙. 모든 섹션은 매 사이클마다 적용됩니다: 루프 전과 도중에 참고하고, 이후에는 참고하지 마십시오.
코드베이스를 탐색할 때는 CONTEXT.md (존재하는 경우)를 읽어 테스트 이름과 인터페이스 어휘가 프로젝트의 도메인 언어와 일치하도록 하고, 작업 중인 영역의 ADR을 존중하십시오.
좋은 테스트란 무엇인가
테스트는 구현 세부사항이 아닌 공개 인터페이스를 통해 동작을 검증합니다. 코드는 완전히 바뀔 수 있지만, 테스트는 바뀌지 않아야 합니다. 좋은 테스트는 명세서처럼 읽힙니다: "사용자는 유효한 장바구니로 체크아웃할 수 있다"는 정확히 어떤 기능이 존재하는지 알려주며, 내부 구조에 신경 쓰지 않기 때문에 리팩터링에도 견딥니다.
예제는 tests.md를, 모킹 지침은 mocking.md를 참조하십시오.
Seam: 테스트를 배치할 위치
Seam은 테스트 대상의 공개 경계입니다: 내부를 들여다보지 않고 동작을 관찰하는 인터페이스. 테스트는 seam에 위치하며, 절대 내부에 대항하지 않습니다.
사전에 합의된 seam에서만 테스트하십시오. 테스트를 작성하기 전에, 테스트 대상 seam을 기록하고 사용자와 확인하십시오. 확인되지 않은 seam에서는 테스트를 작성하지 않습니다. 모든 것을 테스트할 수는 없으므로, 사전에 seam을 합의함으로써 테스트 노력이 모든 경계 케이스 대신 중요한 경로와 복잡한 로직에 집중됩니다.
질문: "공개 인터페이스는 무엇이며, 어떤 seam을 테스트해야 합니까?"
인터페이스의 형태 자체가 의문스러운 경우 (모듈의 깊이, seam의 위치, 인터페이스가 노출해야 할 것), 'codebase-design' Skill 도구를 호출하여 용어를 확인하십시오. 이 도구는 모듈, 인터페이스, 깊이, seam, 어댑터, 지렛대, 지역성 용어의 공유 소스이며, 실행할 세션이 아니라 참조할 자료입니다.
안티패턴
- 구현 결합형: 내부 협력자를 모킹하거나, 비공개 메서드를 테스트하거나, 사이드 채널(인터페이스 대신 데이터베이스 쿼리)을 통해 검증합니다. 징후: 리팩터링했는데 동작이 변하지 않았는데도 테스트가 깨집니다.
- 동어반복형: 단언문이 코드와 동일한 방식으로 기댓값을 재계산합니다(
expect(add(a, b)).toBe(a + b), 동일한 방식으로 수동 파생된 스냅샷, 자신과 동일하게 단언된 상수). 따라서 구조상 항상 통과하며 코드와 불일치할 수 없습니다. 기댓값은 반드시 독립적인 진실 공급원(known-good 리터럴, 계산 예제, 명세)에서 와야 합니다. - 수평 분할형: 모든 테스트를 먼저 작성한 후 모든 구현을 작성합니다. 대량 테스트는 상상된 동작을 검증합니다: 사용자 대면 동작보다는 사물의 _형태_를 테스트하고, 테스트는 실제 변경에 둔감해지며, 구현을 이해하기 전에 테스트 구조에 확정됩니다. 대신 수직 분할로 작업하십시오: 하나의 테스트 → 하나의 구현 → 반복, 각 테스트는 이전 사이클이 가르쳐준 것에 반응하는 추적자 탄환입니다.
루프의 규칙
- 레드에서 그린으로. 먼저 실패하는 테스트를 작성하고, 그런 다음 통과시키기에 충분한 코드만 작성하십시오. 미래의 테스트를 예상하거나 추측성 기능을 추가하지 마십시오.
- 한 번에 한 조각씩. 한 사이클에 하나의 seam, 하나의 테스트, 하나의 최소 구현.
- 리팩터링은 루프의 일부가 아닙니다. 리팩터링은 리뷰 단계(
matt-code-review스킬 참조)에 속하며, 레드-그린 구현 사이클에 속하지 않습니다.