---
name: tdd
description: VideoDownloader 에서 기능을 추가하거나 버그를 고칠 때 쓰는 RED→GREEN→증거 폐쇄루프 절차. 실패 테스트를 먼저 만들고, 최소 구현으로 통과시키고, 실행 증거까지 남긴다. "기능 추가", "버그 수정", "TDD로", "테스트부터" 같은 작업에 사용.
---

# TDD 폐쇄루프

이 저장소는 RED→GREEN→증거로 개발해 왔다. 이 순서를 건너뛰지 않는다.

## 0. 기준선 확보 (건너뛰지 말 것)

```powershell
dotnet test VideoDownloader.Tests
```

지금 몇 개가 통과하는지 **숫자를 기록**한다. 이미 깨져 있다면 그것부터 사용자에게 알린다.
내 변경으로 깨진 것과 원래 깨져 있던 것을 섞지 않기 위해 반드시 먼저 한다.

## 1. RED — 실패를 먼저 본다

고칠 동작을 **재현하는 테스트**를 쓴다.

- 위치: `VideoDownloader.Tests/<영역>/<대상>Tests.cs`
  (영역 = `Browser` · `E2E` · `Infrastructure` · `Mobile` · `Platform` · `Server`)
- 순수 로직이면 `Core`/`Mobile.Core` 쪽으로 밀어 넣어 UI 없이 테스트되게 만든다.
  WPF 의존이 꼭 필요하면 `Infrastructure/WpfTestApp.cs` 패턴을 따른다.
- 사용자 데이터 경로를 건드리는 테스트는 `VD_DATA_DIR` 로 격리한다.

```powershell
dotnet test VideoDownloader.Tests --filter "FullyQualifiedName~<새테스트이름>"
```

**실패하는 것을 눈으로 확인한다.** 여기서 통과해 버리면 테스트가 대상을 못 잡고 있는 것이다.
테스트를 고쳐서 진짜 실패하게 만든 다음 진행한다.

## 2. GREEN — 최소 구현

- 테스트를 통과시키는 가장 작은 변경만 한다. 겸사겸사 리팩터링하지 않는다.
- 에러를 삼키지 않는다. 빈 `catch`, 가짜 폴백 금지. 근본 원인을 고친다.
- 거대 파일(`MainWindow.xaml.cs` 86KB)은 Grep 으로 위치를 찾아 필요한 구간만 읽고 고친다.

```powershell
dotnet test VideoDownloader.Tests
```

**전체**가 통과해야 한다. 기준선보다 테스트 수가 줄면 무언가를 지운 것이다 — 되돌린다.

## 3. 증거 — 테스트로 부족한 것

UI·플랫폼 동작을 바꿨다면 테스트 GREEN 만으로는 "된다"는 근거가 아니다.

| 바꾼 것 | 확인 방법 |
|---|---|
| WPF 화면·상호작용 | `dotnet run --project VideoDownloader.App` 로 실제 창을 띄워 확인 |
| WebView2 감지·쿠키 | 실제 사이트를 열어 미디어가 목록에 잡히는지 확인 |
| 서버 API | 앱 기동 후 해당 엔드포인트 호출 |
| MAUI 화면 | Android 에뮬레이터에 배포해 확인 |
| 다운로드 엔진 | `dotnet run --project VideoDownloader.Cli -- <검증 옵션>` |

무엇을 어떻게 확인했는지 보고에 쓴다. "확인했습니다"만 쓰지 말고 관측한 내용을 쓴다.

## 4. 마무리

- `docs/BACKLOG.md` 해당 항목 `- [ ]` → `- [x]`
- 계획 대비 구현 상태가 바뀌었으면 `docs/IMPLEMENTATION_AUDIT.md` 갱신
- 보고에는 **실제 테스트 출력의 숫자**를 인용한다 (예: "164/164 통과"). 기억으로 쓰지 않는다.

## 막혔을 때

- 원인을 모르겠으면 추측으로 코드를 바꾸지 말고, 먼저 재현 범위를 좁히는 테스트를 더 쓴다.
- 그래도 안 되면 무엇을 시도했고 무엇이 관측됐는지 정리해 사용자에게 보고한다.
  통과하지 못한 것을 통과한 것처럼 쓰지 않는다.