---
name: tdd
description: "사용자가 명시적으로 TDD, 실패하는 테스트 또는 회귀 테스트를 요청할 때만 사용하거나, 버그에 명백한 저렴한 로컬 테스트 대상이 있을 때 사용하세요. 테스트 경로가 불명확하거나, 비싸거나, 통합이 많거나, 요청되지 않은 경우 건너뛰세요."
disable-model-invocation: true
---

# TDD Bug Fix

명확하고 저렴한 테스트 경로가 있는 버그를 수정할 때 프로덕션 코드를 변경하기 전에 깨진 동작을 실행 가능하게 만드세요. 목표는 수정 전에 실패하고 후에 통과하는 집중된 회귀 테스트입니다.

실용적이지 않을 때 테스트를 강요하지 마세요. 사용 가능한 테스트가 광범위한 하니스 설정, 취약한 목, 느린 엔드 투 엔드 인프라, 프로덕션 전용 상태, 모호한 재현 단계 또는 대규모 관련 없는 픽스처 변동이 필요하면 새 테스트를 추가하지 않고 대신 가장 가까운 유용한 검증을 사용하세요.

## 워크플로우

1. **버그 이해.** 의도된 동작, 현재 동작, 영향을 받는 경로 및 가장 작은 관찰 가능한 재현을 식별하세요.
2. **가장 좁은 실행 가능한 검사 선택.** 해당 코드 경로에 이미 사용된 가장 가까운 단위, 구성 요소, 통합 또는 회귀 테스트를 선호하세요. 명백한 실용적인 테스트 경로가 없으면 워크플로우를 만족시키기 위해 처음부터 만들지 마세요.
3. **먼저 실패하는 테스트 작성.** 버그를 잡았을 가장 작은 집중된 테스트를 추가하세요. 테스트는 현재 구현을 미러링하는 것이 아니라 의도된 동작을 인코딩해야 합니다.
4. **수정하기 전에 새 테스트 실행.** 의도한 이유로 실패하는지 확인하세요. 통과하거나 관련 없는 이유로 실패하면 구현을 편집하기 전에 테스트 또는 재현을 수정하세요.
5. **버그 수정.** 근처 계약을 보존하면서 의도된 동작을 만족하는 가장 작은 프로덕션 변경을 하세요.
6. **회귀 테스트 다시 실행.** 테스트가 이제 통과하는지 확인하세요.

## 실패하는 테스트가 실용적이지 않은 경우

대신 가장 가까운 실행 가능한 회귀 검사를 사용하세요: 타겟팅된 스크립트, 수동 재현 명령, 브라우저 자동화, 스냅샷 비교, 로그 주장 또는 집중된 통합 검사.

나쁜 테스트보다 새 테스트 없음을 선호하세요. 나쁜 테스트는 대부분 목을 테스트하거나, 현재 구현 세부 사항을 인코딩하거나, 타이밍 또는 관련 없는 전역 상태에 의존하거나, 작은 수정을 위해 비싼 인프라가 필요하거나, 수정을 증명한 직후 삭제될 테스트입니다.

## 가드레일

- 틀린 구현과 일치하도록 테스트를 변경하지 마세요.
- 예상 동작이 진정으로 변경되고 이유가 명확하지 않는 한 기존 주장을 약화시키지 마세요.
- 회귀 테스트를 버그에 집중하세요. 광범위한 픽스처 변동이나 관련 없는 커버리지 확장을 피하세요.
- 버그가 불안정하면 가능한 곳에서 테스트를 결정론적으로 만들고 고정되는 신호를 문서화하세요.
- 버그가 더 광범위한 실패 클래스를 노출하면 먼저 집중된 회귀 경로를 착륙시킨 다음 추가 형제 커버리지를 고려하세요.

## 최종 응답

결과만이 아니라 증거를 보고하세요:

- 실패 전 테스트 또는 실행 가능한 검사와 생성한 실패를 명명하세요.
- 통과 후 테스트 실행과 수행된 근처 검증을 명명하세요.
- 실패 전 증거를 보여줄 수 없었다면 이유를 진술하고 대신 사용된 가장 가까운 회귀 검사를 설명하세요.