write-test— agent skill

입력

$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가 있으면 해당 문서의 규칙을 따른다. 없으면 아래 기본 원칙 적용:

• 테스트 이름: 상황 시 기대 결과 형식으로 의도를 명확하게
• 시나리오 서술: 사용자 동작과 관찰 가능한 결과로 서술, 내부 상태값/메서드명 직접 노출 금지
• ❌ PomodoroPlayPause → timerState==RUNNING
• ✅ 재생 버튼을 누르면 → 집중 타이머가 시작된다
• 검증 대상: 행동(behavior), 내부 구현 세부사항 금지
• Fake/Mock 위치: 대상 파일과 같은 feature 패키지 하위에 배치

생성 순서:

1. 필요한 Fake 클래스 먼저 생성
2. 테스트 클래스 생성 (계획의 테스트 케이스 순서대로)

5. 리뷰 및 피드백 [STOP]

생성된 테스트 코드를 아래 기준으로 자체 리뷰 후 출력:

## 테스트 리뷰

### ✅ 잘된 점

### ⚠️ 개선 사항
- 누락된 경계 조건
- 가이드라인 위반 사항
- 테스트 격리 문제

### 📝 총평

리뷰 출력 후 반드시 멈출 것 — 사용자 피드백 수렴 후 수정 여부 결정

행동 원칙

• $ARGUMENTS 없으면 먼저 "어떤 코드에 대한 테스트를 작성할까요?" 질문
• 파일 수정 전 반드시 해당 파일 Read
• 코드 언급 시 항상 파일경로:라인번호 형식으로 위치 명시
• 커밋은 사용자가 명시적으로 요청할 때만 진행