agentsclimarketplace

Android test

Skill gagip/gagip-dev/plugins/mobile/skills/android-test

개발 전용 Claude Code 플러그인

Install
npx -y skills add gagip/gagip-dev --skill android-test

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

대상 코드를 분석하고 테스트 시나리오를 함께 논의한 뒤 테스트 코드를 생성. 사용자가 "테스트 써줘", "테스트 만들어줘", "테스트 코드 짜줘", "이 클래스 테스트", "단위 테스트 추가" 등을 요청할 때 사용. 코드 분석 없이 바로 테스트 코드를 작성하려 할 때도 이 스킬을 먼저 참조할 것.

SKILL.md

4.4 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it

입력

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.