write-testlisted

## 입력 ``` $ARGUMENTS ``` ## 참조 문서 코드 분석 전에 먼저 읽는다: - `docs/testing.md` — 테스트 가이드라인 전체 - `docs/architecture.md` — 테스트 전략 (슬라이스 통합/단위/E2E 계층) 파일이 없으면 해당 문서 없이 일반 관례로 진행하고, 사용자에게 알린다. Android 프로젝트(`.kt` 파일, `build.gradle`, `AndroidManifest.xml` 등이 존재)라면 추가로 읽는다: - `${SKILL_DIR}/references/android-test-guidelines.md` — Android 테스트 규칙 (BehaviorSpec, Fake/Mock 전략, StateFlow 검증 방법 등) --- ## 작업 순서 ### 1. 대상 코드 분석 `$ARGUMENTS`로 받은 파일 또는 클래스를 Read/Glob으로 읽는다. 파악할 것: - 클래스의 책임과 공개 인터페이스 - 상태 전환이 있는 로직 - 의존성 (Repository, 시스템 클래스 등) - 복잡한 비즈니스 로직과 경계 조건 분석 후 아래 형식으로 요약 출력: ``` ## 분석 결과: <클래스명> **책임**: (한 줄 요약) **테스트 계층**: 단위 테스트 / 슬라이스 통합 테스트 / E2E (이유 포함) **의존성**: (테스트에 영향을 주는 것만) **주요 시나리오 후보**: - [ ] (시나리오 1) - [ ] (시나리오 2) ... ``` --- ### 2. 테스트 시나리오 논의 [STOP] 분석 결과를 출력한 뒤 **반드시 멈추고** 사용자와 논의한다. 질문 예시: - "이 중에서 우선순위가 높은 시나리오가 있나요?" - "추가로 테스트해야 할 경계 조건이 있나요?" - "X 의존성은 Fake로 처리할까요, Mockk를 쓸까요?" 규칙: - 한 번에 하나만 질문 - 시나리오 목록이 확정되면 3단계로 진행 --- ### 3. 테스트 계획 출력 후 승인 요청 [STOP] ``` ## 테스트 계획: <클래스명> ### 테스트 파일 위치 `<대상 파일의 패키지 경로>/<ClassName>Test.kt` (대상 파일의 패키지 구조를 따름) ### 필요한 Fake/Mock | 의존성 | 방식 | 이유 | |--------|------|------| | `XRepository` | Fake | 인터페이스 구현 가능 | ### 테스트 케이스 목록 | # | 테스트 이름 | 계층 | |---|------------|------| | 1 | `상황 시 기대 결과` | 단위 | | 2 | ... | | 진행할까요? ``` 승인 → 4단계 진행 / 수정 요청 → 계획 수정 후 재대기 --- ### 4. 테스트 코드 생성 **가이드라인 준수 사항** (`docs/testing.md` 기준): `docs/testing.md`가 있으면 해당 문서의 규칙을 따른다. 없으면 아래 기본 원칙 적용: - 테스트 이름: `상황 시 기대 결과` 형식으로 의도를 명확