Retrofit + OkHttpを使用したAPIクライアント実装のベストプラクティスを提供する。 「API実装」「APIクライアント」「Retrofit」「OkHttp」「ネットワーク」と言われたら使う。
android-test-runner
重要: ユーザーがAndroidテスト実行をリクエストした場合、常にこのスキルを最初に使用してください。以下の場合に必ず使用: run TestName, execute test, テストを実行, 結果を分析, run all tests, analyze test failures, fix failing tests、または Android unit test, instrumentation test, Gradle test コマンドに関連する任意のリクエスト。./gradlew test や Bash コマンドを直接使用しないでください - 常にこのスキルに委譲してください。Multi-variantプロジェクト、JAVA_HOME セットアップ、一般的なテストパターンに対応しています。
インストール方法を見る含まれるファイル(5)
- SKILL.md11.7 KB
- knowledge/project-template.md5.2 KB
- knowledge/test-failure-patterns.md22.1 KB
- README.md4.3 KB
- templates/fix-suggestions.md6.5 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Android Test Runner
Android テスト実行を自動化し、テスト失敗を分析し、実行可能な修正提案を提供する Claude Code スキルです。
目的
このスキルは Android 開発者を支援します:
- Claude Code から直接テストを実行
- テスト失敗の根本原因を自動的に分析
- 失敗したテストに対する具体的な修正提案を取得
- デバッグ時間を30%以上削減
Quick Reference
最も一般的なエラー
| エラーメッセージ | Pattern | クイックフィックス |
|---------------|---------|-----------| | Unable to locate a Java Runtime | 6, 12 | export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" |
| Unknown command-line option '--tests' | 5, 11 | ./gradlew :module:testVariantDebugUnitTest |
| No answer found for: (MockK) | 2 | every { mock.method() } returns value |
| No value passed for parameter | 7, 13 | 不足しているコンストラクタパラメータを追加 |
| Test not found (Compose UI) | 17 | androidTest/ に移動 |
| NoSuchElementException (Flow) | 19 | Turbine の .test {} を使用 |
| expected: X but was: Y | 8, 14 | Mock データを確認 |
| CI失敗、ローカル成功 | 16, 18 | すべてのバリアントをテスト ./gradlew test |
詳細は knowledge/test-failure-patterns.md を参照
使い方
テスト実行
User: すべてのunit testを実行して
Assistant: [./gradlew test を実行し結果を分析]
User: UserRepositoryのテストを実行して
Assistant: [./gradlew test --tests "*UserRepositoryTest" を実行し結果を分析]
失敗分析
テストが失敗すると、このスキルは自動的に:
- テスト出力ログを解析
- 失敗パターンを特定(NullPointerException, Mock設定問題等)
- コード例付きの具体的な修正提案を提供
修正提案の取得
User: LoginViewModelTestが失敗した理由は?
Assistant: [テスト失敗ログを分析し以下を提供:
- 根本原因の説明
- 関連するコードスニペット
- コード例付きの具体的な修正]
System Instructions
ユーザーが Android テストの実行やテスト失敗の分析をリクエストした場合、以下の手順に従ってください:
0. 環境セットアップ & プロジェクト検出(必須 - 常に最初に実行)
テストを実行する前に、環境を確認・設定してください:
ステップ1: JAVA_HOME 確認
# JAVA_HOMEが設定されているか確認
if [ -z "$JAVA_HOME" ]; then
# macOS: Android Studio JBR を自動検出
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
fi
# 確認
$JAVA_HOME/bin/java -version
エラー検出:
- "Unable to locate a Java Runtime" が表示された場合 → JAVA_HOMEを設定して再試行
ステップ2: プロジェクト構造検出
# ビルドバリアントを検出(存在する場合)
./gradlew tasks --all | grep "test.*UnitTest"
# 出力例(multi-variantプロジェクト):
# :app:testDevelopDebugUnitTest
# :app:testDevelopReleaseUnitTest
# :app:testProductionDebugUnitTest
ビルドバリアント検出:
- 複数の
testXxxDebugUnitTestタスクが存在 → プロジェクトにビルドバリアントあり Unknown command-line option '--tests'エラー → バリアント固有タスクを使用する必要あり
BuildType認識: 本番プロジェクトには複数のBuild Typeが存在することが多い:
Debug: 通常のテスト実行(最も一般的)Release: リリースビルドCiRelease: CI専用リリースビルドMinified: 難読化テストビルド
総バリアント数 = Product Flavors × Build Types
- 例: 4 flavors × 3 build types = 12 variants
- 日常開発:
Debugビルドタイプのみテスト - コミット前: すべてのflavorsを
Debugでテスト(./gradlew :module:testDebug) - リリース前: すべてのバリアントをテスト(
./gradlew :module:test)
ステップ3: テストタスク決定
ビルドバリアントありのプロジェクト:
# 単一バリアント(最速、クイックチェック用)
./gradlew :module:testVariantDebugUnitTest
# すべてのバリアント(CI相当、コミット前推奨)
./gradlew :module:test
ビルドバリアントなしのプロジェクト:
# 標準コマンドが動作
./gradlew test
./gradlew test --tests "*TestClass"
1. テスト実行(拡張版)
Bashツールを使用してGradleテストコマンドを実行してください。重要: 常に最初にJAVA_HOMEを設定してください(ステップ0から)。
パターンA: 標準プロジェクト(ビルドバリアントなし)
# すべてのunit test
./gradlew test
# 特定のテストクラス
./gradlew test --tests "*UserRepositoryTest"
# 特定のテストメソッド
./gradlew test --tests "*UserRepositoryTest.testGetUser"
# 詳細出力付き
./gradlew test --info
パターンB: Multi-Variantプロジェクト(本番環境で一般的)
# JAVA_HOME設定 + 単一バリアントテスト
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && \
./gradlew :module:testVariantDebugUnitTest
# すべてのバリアント(CI相当、コミット前推奨)
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && \
./gradlew :module:test
# 特定モジュールの特定バリアント
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home" && \
./gradlew :data:testProductionDebugUnitTest
エラーハンドリング & 自動再試行
エラー1: Unknown command-line option '--tests'
- 原因: プロジェクトに複数のビルドバリアントあり
- 修正: バリアント固有タスクに切り替え
# バリアントを検出
./gradlew tasks --all | grep "test.*UnitTest"
# バリアントタスクを使用
./gradlew :module:testVariantDebugUnitTest
エラー2: Unable to locate a Java Runtime
- 原因: JAVA_HOME未設定
- 修正: JAVA_HOMEを設定して再試行
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
./gradlew :module:testVariantDebugUnitTest
重要:
- 常にプロジェクトルートディレクトリから実行
- 常にAndroidプロジェクトでJAVA_HOMEを設定
- テストコマンドを選択する前にビルドバリアントを検出
- 標準出力と標準エラー出力の両方をキャプチャ
- コミット前にすべてのバリアントのテストを推奨(CIパリティ)
2. テスト結果の解析
テスト実行後、出力を分析:
成功インジケータ:
- "BUILD SUCCESSFUL"
- "X tests completed, X passed"
失敗インジケータ:
- "BUILD FAILED"
- "X tests completed, X failed"
- 出力中のスタックトレース
抽出:
- 失敗したテストクラス名
- 失敗したテストメソッド名
- 例外タイプとメッセージ
- スタックトレースの場所
3. 失敗パターン分析
失敗を一般的なパターンと照合(完全なリストは knowledge/test-failure-patterns.md を参照):
一般的なパターン:
- Pattern 1: NullPointerException
- Pattern 2: MockK: No Answer Found
- Pattern 3-10: 標準的なテスト失敗
- Pattern 11-16: Multi-variantプロジェクト固有の問題
- Pattern 17-19: 高度なパターン(Compose UI, BuildType, Flow)
4. 修正提案の提供
レスポンスを以下の形式でフォーマット:
## テスト失敗分析
**失敗したテスト**: `UserRepositoryTest.testGetUser()`
**根本原因**: MockK mock が `userApi.getUser()` に対して設定されていない
**修正方法**:
`UserRepositoryTest.kt:45` で、mock設定を追加:
```kotlin
@Before
fun setup() {
every { userApi.getUser() } returns Result.success(mockUser)
}
説明:
テストが userApi.getUser() を呼び出していますが、MockKは何を返すべきか分かりません。
every { ... } returns ... を使用してmockの動作を定義する必要があります。
### 5. ナレッジ参照
一般的なパターンについては、以下のナレッジファイルを参照:
- `knowledge/test-failure-patterns.md` - 一般的なAndroidテスト失敗パターン(19パターン)
- `knowledge/project-template.md` - プロジェクト固有のカスタマイズ用テンプレート
- `templates/fix-suggestions.md` - 修正提案用テンプレート
## 重要事項
- 常にプロジェクトルートから実行
- ログを注意深く解析して正確な失敗場所を特定
- ファイルパスと行番号を提供(例: `UserRepository.kt:25`)
- 修正提案時に実際のテストファイルからコードスニペットを含める
- テスト修正は最小限で焦点を絞ったものに
- プロジェクト固有のパターンについては、プロジェクト固有のナレッジファイルを参照
## カスタマイズ
### プロジェクト固有版の作成
最大の精度(80% → 98%)を得るために、プロジェクト固有版を作成:
1. このスキルをプロジェクトにコピー:
```bash
cp -r android-test-runner your-project/.claude/skills/
knowledge/project-specific.mdを以下の内容で作成:- ビルドバリアントとビルドタイプ
- プロジェクト標準のテストライブラリ
- アーキテクチャパターン(Result型、Flow型等)
- CI/CD設定
- プロジェクト固有の一般的な失敗パターン
開発ワークフローについては ~/.config/claude-code/AI_DEVELOPMENT_GUIDELINES.md を参照。
成功基準
- ✅ Gradle経由でテストを実行可能
- ✅ 失敗の根本原因を正確に特定(70%以上の精度)
- ✅ 実行可能な修正提案を提供
- ✅ デバッグ時間を30%以上削減
互換性
Agent Skills (Open Standard)
このスキルは Agent Skills オープンスタンダードに準拠しています。
対応ツール:
- Claude Code ✅
- GitHub Copilot ✅
- VS Code ✅
- Cursor (Nightly) ✅
- OpenAI Codex ✅
.claude/skills/ ディレクトリに配置することで、上記すべてのツールで使用可能です。
バージョン
v1.1 - Agent Skills対応 (2025-12-23)
- ✅ Agent Skills オープンスタンダード準拠を確認
- ✅ 互換性セクション追加
- ✅ 複数コーディングエージェントで使用可能
v1.0 - 汎用版リリース (2025-11-20)
- ✅ Pattern 1-19 を実装
- ✅ Multi-variantプロジェクトサポート
- ✅ JAVA_HOME 自動設定
- ✅ Quick Reference 追加
- ✅ 包括的なドキュメント
- ✅ すべての説明を日本語で記述(視認性・メンテナンス性向上)
android-test-runner v0.2(プロジェクト固有版、98%精度)をベースにしています
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Androidプロジェクトのアーキテクチャ設計を支援。プロジェクト特性に応じてMVI/MVVM/シンプルComposeから最適なパターンを提案し、パッケージ構造の設計と既存プロジェクトの分析を行う。
Firebase Crashlyticsのスタックトレースを解析し、トリアージ分類→根本原因分析→修正提案を出力するスキル。/crash-analyze コマンド、クラッシュ解析、スタックトレース分析、ANR分析、Crashlytics、クラッシュレポート、またはFirebase crashに関連するリクエストで使用される。クラッシュ対応のワークフローを標準化し、対応品質と速度を向上させる。ANR/Non-fatal/Fatal全タイプ対応。
Android data layer implementation guide. Provides comprehensive patterns for Room Database (Entity, DAO, Migration), DataStore (Preferences), Repository layer design, and common pitfalls. Use when implementing local data storage, cache strategies, or data source integration in Android projects.
日本語の概要は準備中です。原文の説明を表示しています。
Jetpack ComposeでUIを実装する時に参照するコーディングガイドライン。 「Android UI」「Compose」「Jetpack」「画面実装」「UIコンポーネント」「レイアウト」と言われたら使う。 Android/Kotlin UI実装のベストプラクティス、アンチパターン、実装パターンを提供する。
非同期処理のバックエンドとフロントエンドを実装する際のベストプラクティスをまとめたスキルです。非同期処理が必要なWebサービスのフロントエンドおよびバックエンドを実装する際に利用されます。