Gradleのインストルメント化されたテストの実行をアプリのアンインストールから停止するにはどうすればよいですか？

8

もし私が：

新しいAndroid Studio 3.5.1プロジェクトを作成します（Kotlin、API 21、「空のアクティビティ」テンプレート）
IDE内からアプリを実行する
アプリがインストールされており、ランチャーアイコンがあることを確認します
connectedAndroidDebugTestGradleタスクを実行する（Android Studio内から、またはを介してgradlew）

アプリは、テスト実行によってアンインストールされることになります。テストコードで別のアプリケーションIDを使用するようにtestApplicationId値を追加しても、この動作が発生しdefaultConfigます。

その動作を停止するにはどうすればよいですか？既存のアプリのインストールに影響を与えずに、コマンドラインからインストルメント化されたテストを実行するにはどうすればよいですか？

android android-gradle-plugin

— CommonsWare
ソース

2

このstackoverflow.com/questions/47670066/…と同様（彼らは解決策を得られませんでしたが、いくつかの回避策です）

— Tyler V

@TylerV：問題は、1年前にこれができなかったことを私は誓います。統合されたカバレッジレポートにGradleタスクを使用します（インストゥルメント化テストと単体テストの出力をマージします）。私は1年前のプロジェクトでそれを使用していましたが、この問題に遭遇したことを覚えていません。新しいプロジェクトでレポートを再度実装したところ、アンインストールの問題が発生しています。1年前のことはぼんやりしているのかもしれませんが、認証が必要なアプリをアンインストールするのは面倒なので、覚えておきたいと思います。

— CommonsWare

個々のテストファイルを右クリックしてそのように実行すると、完了時にアプリがアンインストールされません（アプリに事前入力されたデータを読み込むためにこれを時々実行します）。これはおそらく、接続されたテストタスクに追加されたステップです...

— Tyler V

2

connectedCheckタスクは種類がありますDeviceProviderInstrumentTestTask。1つのデバイスで単純なテストを実行する場合はSimpleTestRunner、を使用しSimpleTestRunnableます。次に、を使用して実際にテストを実行します。ここであなたはの構造を見つけます

try {
    // connect to device
    // install all APKs
    // run tests
} catch(Exception e) {
    // handle error
} finally {
    // get test report
    // uninstall all APKs
    // disconnect from device
}

最新の実装が見つかったかどうかは完全にはわかりませんが、この正確な動作は数年前に遡ります。だから、あなたが求めていることを達成することはできないと思います。

— tynn
ソース

3

たぶん次のadbようにして実行してみてください：

adb shell am instrument -w com.android.demo.app.tests/android.support.test.runner.AndroidJUnitRunner

アプリはアンインストールされません。

ここでは、より詳細に説明します。

— パブロオスタシャ
ソース

1

これは、状況によっては実用的かもしれません。私の場合、私は本当に実行したいという課題があるcreateDebugCoverageReportに依存しています、connectedAndroidDebugTest。だから、connectedAndroidDebugTestどういうわけか書き直さない限り、私は避けられませんcreateDebugCoverageReport。

— CommonsWare、

回答で提供した公式ドキュメントへのリンクには、で使用できるadb コマンドオプションのリストがam instrumentありますam instrument。また、emmaオプションをに設定すると、adbを介してカバレッジレポートを実行できますtrue。また、coverageFile オプションを使用して、カバレッジレポートの宛先ファイルを変更できます。それが役に立てば幸い。

— Pavlo Ostasha

「そして、emmaオプションをtrueに設定して、adbを介してカバレッジレポートを実行できます。」-私の知る限り、Androidは何年もの間emmaのカバレッジを使用しておらず、ずっと前にJacocoに切り替えてきました。実装を変更している間、オプション名を同じにしておいたかもしれません...

— CommonsWare

多分-詳細はわかりません。しかし、そのような可能性があります。

— Pavlo Ostasha

2

インストルメンテーションは2つのAPKをインストールします：テスト対象のAPKとテストコードを含むAPK。

また、新しいAPKをインストールしようとする前に両方のAPKをアンインストールしますが、アンインストール自体を防止できるかどうかはわかりません。

testApplicationIdテストコードを含むAPKのアプリケーションIDのみを変更します（通常、「。test」が追加されたメインAPKの場合と同じです）。テスト中のAPKのアプリケーションIDは変わりません。ただし、テスト対象のAPKに個別のbuildTypeを作成し（デバッグビルドタイプとまったく同じ構成で）、それを使用することは可能です。

次にconnectedAndroidXYZTest、テスト（またはcreateXYZCoverageReport）を実行するために使用できます。

— ジョセフ・アダムシック
ソース

1

tynnの質問は最も正確なものなので、私はtynnの回答を受け入れます。私はあなたに最も安全な回避策の恩恵を与えています...あなたのコードが実行時にビルドタイプに基づいて何もしないことを前提としています。その場合は、XYZそのコードでビルドタイプを覚えておく必要があります。

— CommonsWare、

正しい@CoommonsWare。私は通常、ビルドタイプのチェックを直接避け、gradleで「buildConfigField」ディレクティブを使用して、BuildConfigクラスにブールフラグ（または問題に適したもの）を生成します。

— Josef Adamcik