releases/.claude/skills/tdd/SKILL.md

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

TDD 폐쇄루프

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

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

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 로 격리한다.

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

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

2. GREEN — 최소 구현

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

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 통과"). 기억으로 쓰지 않는다.

막혔을 때

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