Scan to join WeChat groupAndroid 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%以上削減
バージョン
v1.0 - 汎用版リリース (2025-11-20)
- ✅ Pattern 1-19 を実装
- ✅ Multi-variantプロジェクトサポート
- ✅ JAVA_HOME 自動設定
- ✅ Quick Reference 追加
- ✅ 包括的なドキュメント
- ✅ すべての説明を日本語で記述（視認性・メンテナンス性向上）
android-test-runner v0.2（プロジェクト固有版、98%精度）をベースにしています