---
name: tdd
description: Test-Driven Development 방법론 스킬
compatibility: omp
---
# TDD (Test-Driven Development) Skill
테스트를 먼저 작성하고 구현하는 RED-GREEN-REFACTOR 사이클을 적용하는 스킬입니다.
## 핵심 원칙
**테스트 없이 코드를 작성하지 않는다.** 동작이 바뀌는 코드는 그 동작을 정의하는 테스트를 먼저 쓰고, 테스트 없이 동작을 바꾸는 요청은 거부한다. 읽기 전용 조사, 문서, 기계적 리네이밍처럼 관찰 가능한 동작이 바뀌지 않는 작업에는 적용하지 않는다.
좋은 테스트는 **public interface를 통해 동작을 검증**하며 구현 세부를 모른다. 코드가 통째로
바뀌어도 테스트는 바뀌지 않아야 한다. 좋은 테스트는 명세처럼 읽힌다: "유효한 장바구니로 결제할
수 있다"는 어떤 능력이 존재하는지 정확히 말하고, 내부 구조에 무관하므로 리팩토링을 견딘다.
탐색할 때 `CONTEXT.md`(있으면)를 읽어 테스트 이름과 인터페이스 어휘를 도메인 언어에 맞춘다.
## Seam: 테스트가 놓이는 자리
**seam**은 테스트하는 public 경계다 — 안을 들여다보지 않고 동작을 관찰하는 인터페이스.
테스트는 seam에 산다. 내부에 대고 쓰지 않는다.
**사전에 합의된 seam에서만 테스트한다.** 테스트를 쓰기 전에 테스트 대상 seam을 적고 사용자와
확인한다. 합의되지 않은 seam에는 테스트를 쓰지 않는다. 전부 테스트할 수는 없으므로 seam을
먼저 합의하는 것이 테스트 노력을 모든 엣지 케이스가 아니라 핵심 경로와 복잡한 로직에 놓는
방법이다. 물어라: "public interface가 무엇이고, 어느 seam을 테스트해야 하나요?"
인터페이스의 모양 자체가 문제일 때(모듈이 얼마나 깊은지, seam이 어디 놓여야 하는지)는
`codebase-design` 스킬의 어휘(module, interface, depth, seam, adapter)를 참조한다.
## 안티패턴
- **구현 결합**: 내부 협력자를 mock하거나, private 메서드를 테스트하거나, 옆 통로(인터페이스
대신 DB를 직접 조회)로 검증한다. 징후: 동작은 그대로인데 리팩토링하면 테스트가 깨진다.
- **동어반복**: 단언이 코드와 같은 방식으로 기대값을 다시 계산한다(`assert.Equal(a+b, add(a,b))`,
같은 방식으로 손으로 만든 스냅샷, 상수를 자기 자신과 비교). 구성상 통과하므로 코드와
불일치할 수 없다. 기대값은 독립된 진실 — known-good 리터럴, 손으로 푼 예제, 스펙 — 에서 온다.
- **수평 슬라이스**: 테스트를 전부 먼저 쓰고 구현을 전부 나중에 쓴다. 뭉텅이 테스트는 *상상한*
동작을 검증하고, 구현을 이해하기 전에 테스트 구조를 확정한다. 대신 **수직 슬라이스**로 일한다:
테스트 하나 → 구현 하나 → 반복. 각 테스트는 직전 사이클이 가르친 것에 반응하는
**tracer bullet**이다.
## RED-GREEN-REFACTOR 사이클
### RED 단계: 실패하는 테스트 작성
```
1. 구현하려는 동작을 테스트로 먼저 작성
2. 테스트가 실패하는지 확인 (컴파일 에러 포함)
3. 올바른 실패 이유인지 확인
```
테스트 작성 원칙:
- 테스트는 하나의 동작만 검증
- 이름은 `Test[Subject]_[Scenario]_[Expected]` 형식
- Given-When-Then 구조 사용
- Table-driven tests로 다양한 케이스 커버
```go
func TestCalculate_WithZeroInput_ReturnsError(t *testing.T) {
t.Parallel()
// Given
input := 0
// When
_, err := Calculate(input)
// Then
assert.Error(t, err)
assert.ErrorIs(t, err, ErrInvalidInput)
}
```
### GREEN 단계: 최소 구현으로 테스트 통과
```
1. 테스트를 통과시키는 가장 단순한 코드 작성
2. 과도한 최적화나 일반화 금지
3. 테스트 통과만을 목표로
```
### REFACTOR 단계: 코드 품질 개선
```
1. 중복 제거 (DRY 원칙)
2. 명명 개선
3. 복잡도 감소
4. 테스트는 항상 그린 상태 유지
```
## 테스트 작성 패턴
프로젝트 테스트 프레임워크의 관용구를 따른다. table-driven을 지원하는 언어에서는 정상/경계/에러 케이스를 한 테이블에 모으고, 각 케이스 이름이 검증하는 동작을 말하게 한다. 위 RED 예시가 이 형식의 최소 형태다.
## 루프의 규칙
- **red가 green보다 먼저.** 실패 테스트를 먼저 쓰고, 그것을 통과시킬 만큼만 코드를 쓴다.
미래의 테스트를 예상하거나 투기적 기능을 넣지 않는다.
- **한 번에 한 슬라이스.** 사이클마다 seam 하나, 테스트 하나, 최소 구현 하나.
- **REFACTOR는 green 뒤에만.** 테스트가 green인 상태에서만 구조를 바꾸고, 리팩토링 중에는
동작을 바꾸지 않는다. 얕은 모듈을 깊게 합칠 때 옛 단위 테스트가 낭비가 되면 지운다
(`codebase-design`의 "교체하되 겹치지 않는다").
## 완료 기준
- [ ] 테스트 대상 seam을 사용자와 합의했다
- [ ] 변경된 동작마다 그것을 단정하는 테스트가 있다
- [ ] 프로젝트 테스트 명령이 통과한다 (동시성 코드는 race 플래그 포함)
- [ ] 테스트 커버리지 85% 이상 (프로젝트가 `workflow.coverage_threshold`로 다른 값을 선언하면 그 값)
Seam 합의·안티패턴·루프 규칙은 mattpocock/skills `tdd`(MIT)에서 가져와 다듬었다.
