---
name: android-test
description: 대상 코드를 분석하고 테스트 시나리오를 함께 논의한 뒤 테스트 코드를 생성. 사용자가 "테스트 써줘", "테스트 만들어줘", "테스트 코드 짜줘", "이 클래스 테스트", "단위 테스트 추가" 등을 요청할 때 사용. 코드 분석 없이 바로 테스트 코드를 작성하려 할 때도 이 스킬을 먼저 참조할 것.
argument-hint: "<파일경로 또는 클래스명>"
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
---

## 입력

```
$ARGUMENTS
```

## 참조 문서

코드 분석 전에 먼저 읽는다 (대상 프로젝트 루트 기준 — 이 스킬 자체의 `references/`가 아니다):

- `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
- 코드 언급 시 항상 `파일경로:라인번호` 형식으로 위치 명시
- **커밋은 사용자가 명시적으로 요청할 때만 진행**