はじめに
普段問題なく動いていた ./gradlew test が、ある日を境に突然すべて落ちることがあります。
- テストコードは変えていない
- 直前のコミットでも通っていた
- エラーログも直接的な原因を示さない
こうした状況では、Gradleキャッシュの破損や不整合が原因であるケースが少なくありません。
この記事では、まず試すと復旧しやすい三つの対処をまとめます。
1. Gradle Daemonを停止する
最初に行うべきは、Gradle Daemonの停止です。
バックグラウンドで保持されている状態が壊れていると、テストが正しく検出されないことがあります。
./gradlew --stop
その後、通常どおりテストを再実行します。
./gradlew test
これだけで復旧することもあります。
2. Gradleキャッシュをクリアする
キャッシュ破損が疑わしい場合は、プロジェクト直下の .gradle ディレクトリを削除します。
rm -rf .gradle
また、ユーザーディレクトリ配下のキャッシュ（~/.gradle）に問題があるパターンもあるため、必要に応じてそちらも削除します。
rm -rf ~/.gradle/caches
削除後はビルドし直すことでキャッシュが再生成されます。
./gradlew test
3. テスト設定まわりの不整合を確認する
キャッシュに起因するテストの不発は、以下の設定が壊れているときも起こります。
テストが検出されないケース
There are test sources present and no filters are applied,
but the test task did not discover any tests to execute.
この場合は、設定値が無効化されている可能性があります。
応急措置としての設定
test {
failOnNoDiscoveredTests = false
}
ただし、これは根本対応ではありません。
多くのケースでは キャッシュ削除→Gradle再生成 で解消します。
それでも直らない場合
- Gradle Wrapperのバージョン不整合
- Kotlin/AGPの更新に端を発する影響
- JUnit/Mockito/Robolectricなどテストランナー系依存の更新
Gradle周りの破損が多いため、まずはキャッシュ/daemon/依存の組み合わせを疑う方が効率的です。
まとめ
-
./gradlew testが突然落ちる場合、キャッシュ起因がよくある - Daemon停止 →
.gradle削除 → 設定確認の順に試す - キャッシュの再生成だけで復旧する例は少なくない
テスト環境の不調で時間を取られがちな場面の助けになればと思います。
さいごに
もう12月で驚きです、今年も残りわずかですね…