Tdd Workflow

---
name: tdd-workflow
description: 새 기능·버그 수정을 테스트 먼저(TDD)로 진행할 때. "TDD로 해줘", "테스트 먼저" 요청이나 회귀가 잦은 영역 작업에 사용.
---

# tdd-workflow — 테스트 먼저

## 절차

1. **실패하는 테스트 먼저** — 구현 전에 기대 동작을 테스트로 적고, 실행해 **실패를 눈으로 확인**한다 (버그 수정이면 재현 테스트). 컴파일 언어에서는 **컴파일 실패도 유효한 RED** 다 — 아직 없는 API 를 호출하는 테스트가 컴파일되지 않는 것이 정확히 기대 상태다.
2. **최소 구현** — 그 테스트를 통과시키는 최소한의 코드만 쓴다.
3. **그린 확인** — 새 테스트 + 기존 스위트 전체를 실행해 회귀가 없음을 확인한다.
4. **리팩토링** — 그린을 유지하며 정리하고, 끝나면 스위트를 다시 돌린다.
5. 다음 동작 단위로 1~4 를 반복한다.

## 커밋 체크포인트 (권장)

단계 경계마다 커밋을 끊으면 증거가 이력에 남는다: `test: <재현/기대> 추가`(RED 상태) → `fix:`/`feat:` `<구현>`(GREEN) → `refactor: 정리`. 스쿼시 머지 후에도 증거가 살아남도록, 마지막에 아래 증거 표를 일지에 남긴다 — `## 검증` 은 규격상 1~3줄 요약이므로, 표는 **`## 메모` 섹션에** 두고 검증에는 "TDD 증거 표는 메모 참조" 한 줄로 가리킨다.

## 증거 표 — 일지 `## 메모` 규격

| 보장하는 것 | 테스트 | RED 확인 | GREEN 명령 |
|---|---|---|---|
| 자정 롤오버가 중복 없이 1회 | today_rollover.test.ts | ✓ (수정 전 실패 확인) | `pnpm vitest run src/__tests__/today_rollover.test.ts` |

- **RED 확인** 열이 비어 있으면 그 행은 TDD 가 아니다 — 사후 테스트로 정직하게 표기한다.

## 규칙

- 테스트가 실패하는 것을 보기 전에는 구현을 시작하지 않는다 (통과부터 하는 테스트는 아무것도 증명하지 못한다).
- 테스트를 통과시키려고 테스트를 약화시키지 않는다 — 기대를 바꿔야 하면 이유를 사용자에게 보고한다.
- 커버리지 숫자보다 시나리오: 해피패스 1개 + 에지 케이스 2개 이상을 기본으로 한다.