インストルメンテーション テストを使ってみる

このガイドでは、Firebase Test Lab を使用してインストルメンテーション テストを準備して実行する方法について説明します。このガイドを使用するには、Espresso を使用するインストルメンテーション テスト（自身またはチームが作成）または UI Automator の Android テスト フレームワークが必要です。インストルメンテーション テストは、実機で最大 45 分、仮想デバイスで最大 60 分かかります。

後で、アプリの APK とテストの APK を Firebase にアップロードします。

（省略可）アプリにスクリーンショット ライブラリを追加する

Firebase Test Lab に含まれているライブラリ（testlab-instr-lib）を使用して、インストルメンテーション テスト（Espresso テスト フレームワークを使用して記述したテストなど）の実行時に AndroidX の ScreenCapture で撮影したスクリーンショットを処理できます。このセクションでは、AndroidX ライブラリを使用して ScreenCapture オブジェクトを作成する方法と、それらのオブジェクトを testlab-instr-lib を使用して処理する方法について説明します。

インストルメンテーション テストの実行後に、キャプチャしたスクリーンショットを Firebase コンソールで表示できます。

サンプルアプリを試してみる

NotePad サンプルアプリをダウンロードして、この機能をお試しください。スクリーンショットの撮影機能は、NotePad プロジェクトにあらかじめ組み込まれています。

ステップ 1. プロジェクトにスクリーンショット ライブラリを追加する

  1. テスト プロジェクトのルートレベルの設定の Gradle ファイル（settings.gradle.kts または settings.gradle）で、すべての repositories セクションに Google の Maven リポジトリを追加します。

    pluginManagement {
    repositories {
        // Add the following line:
        google() // Google's Maven repository
        mavenCentral()
        gradlePluginPortal()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        // Add the following line:
        google() // Google's Maven repository
        mavenCentral()
    }
}
// ...

  2. モジュール（アプリレベル）の Gradle ファイル（通常は <project>/<app-module>/build.gradle.kts または<project>/<app-module>/build.gradle）に、Test Lab スクリーンショット ライブラリの依存関係を追加します。

    dependencies {
  // ...
  // Add Test Lab's instrumentation test screenshot library:
  androidTestImplementation("com.google.firebase:testlab-instr-lib:0.2")
  // ...

  3. テストの AndroidManifest.xml ファイルで、<instrumentation> 要素内の meta-data タグに FirebaseScreenCaptureProcessor を登録します。この手順の代わりに、AndroidJUnitRunner でこのプロセッサを引数として指定することもできます（方法については AndroidJUnitRunner リファレンス ドキュメントをご覧ください）。

    <instrumentation
  // Check that you have the following line (if not, add it):
  android:name="androidx.test.runner.AndroidJUnitRunner" // Specifies AndroidJUnitRunner as the test runner
  android:targetPackage="com.your.package.name">

// Add the following:
<meta-data
  android:name="screenCaptureProcessors"
  android:value="com.google.firebase.testlab.screenshot.FirebaseScreenCaptureProcessor" />
</instrumentation>
...

  4. アプリの AndroidManifest.xml ファイルで、<manifest> 要素内に次の行を追加します。

     <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

  5. AndroidManifest.xml ファイルで、<manifest> タグ内に次の行を追加し、アプリのシステム権限を指定します。Android 10（API レベル 29）以降でテストを行う場合は、WRITE_EXTERNAL_STORAGE 権限を省略します（デバイスでスクリーンショットの読み取り / 書き込みを行う場合、この権限は必要ありません）。

    <manifest ... >
    <!-- WRITE_EXTERNAL_STORAGE is not needed on Android 10 (API level 29) or higher. -->
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.INTERNET"/>
    ...
</manifest>

ステップ 2. テスト中にスクリーンショットを撮影する

テスト中にスクリーンショットを撮影したいタイミングで、AndroidX ライブラリから Screenshot.capture() メソッドを呼び出します。これにより、ScreenCapture オブジェクトが生成されます。ScreenCapture オブジェクトで process() を呼び出すと、AndroidManifest.xml に登録されている ScreenCaptureProcessor を使用して処理が行われます。プロセッサが登録されていない場合は、BasicScreenCaptureProcessor が使用されます。ここでは FirebaseScreenCaptureProcessor が登録済みであるので、スクリーンショットは FirebaseScreenCaptureProcessor によって処理され、Firebase Test Lab でテストを実行すると結果を確認できます。

ScreenCapture を作成するユースケースの例:

  • Build.VERSION_CODES.JELLY_BEAN_MR2 以降の API で、完全な ScreenCapture を取得します。

    Screenshot.capture()

  • 任意の API レベルで、アクティビティの ScreenCapture を取得します。Build.VERSION_CODES.JELLY_BEAN_MR2 以前のデバイスの場合、これが唯一のオプションです。

    @Rule
  public ActivityTestRule<MainActivity> activityRule = new ActivityTestRule<>(MainActivity.class);
...
Screenshot.capture(activityRule.getActivity());
...

ScreenCapture を処理するユースケースの例

  • FirebaseScreenCaptureProcessor を使用して ScreenCapture を処理します。

    Screenshot.capture().process();

  • 指定された ScreenCaptureProcessor を使用して ScreenCapture を処理します（こうするとプロセッサの登録をスキップできます）。

    Set<ScreenCaptureProcessor> processors = new HashSet<>();
processors.add(new FirebaseScreenCaptureProcessor());
Screenshot.capture().process(processors);

  • ScreenCapture の名前と形式を設定し、登録済みのプロセッサを使用して処理します。

    Screenshot.capture().setName("myscreenshot").setFormat(CompressFormat.JPEG).process();

ステップ 3. ビルドしてテストを実行する

  1. アプリとテスト用 APK をビルドします（手順については、アプリをテストするをご覧ください）。

  2. APK ファイルを Firebase コンソールの Test Lab ダッシュボードにアップロードします。

  3. テストを実行します。

ステップ 4. テストのスクリーンショットを確認する

テストが完了したら、撮影されたスクリーンショットを Firebase コンソールで確認できます。

  1. [テスト] タブで完了したテストを選択して、[結果] タブをクリックします。

  2. テストをもう一度選択して、表示される [スクリーンショット] タブをクリックします。

（省略可）追加のテスト機能を有効にする

Test Lab でテストを実行する前に、テストで次の機能を有効にできます。

Orchestrator を有効にする

Android Test Orchestrator は、アプリのインストルメンテーション テストをそれぞれ個別に実行するツールです。 Test Lab では常に Orchestrator の最新バージョンが使用されます。

Test Lab で Orchestrator を有効にするには、インストルメンテーション テストの設定の [詳細オプション] > [Orchestrator を使用して実行] をクリックします。

Orchestrator を使用すると、次のようなメリットがあります。

  • 共有データがない。各テストは独自のインストルメンテーション インスタンスで実行されるため、テストをまたいで共有データが蓄積されることはありません。
  • テストがクラッシュしても、終了するのはそのインストルメンテーションのみであるため、テストスイートに含まれる他のテストは続行されます。

Orchestrator を使用する場合、各テストは独自のインストルメンテーション インスタンスを実行するため、テストケースごとにアプリプロセスが再起動されることに注意してください。その結果として実行時間が長くなると、割り当て使用量や課金される時間に影響を与える可能性があります。また、デバイスのタイムアウト制限を超える場合もあります。アプリの起動時間を短縮すると、このオーバーヘッドは短縮されます。

Orchestrator の追加オプションを設定するには、environmentVariables フィールドで指定します。たとえば、clearPackageData を使用するには、gcloud で次のオプションを使用します。

--environment-variables clearPackageData=true

シャーディングを有効にする

テストのシャーディングによって、一連のテストをサブグループ（シャード）に分割し、それぞれ分離して実行できるようにします。Test Lab は自動的に各シャードを複数のデバイスで並行して実行するため、テスト全体を完了するまでの時間が短縮されます。

たとえば、N 個のシャードを作成した場合、Test Lab は選択したデバイスごとに N 個の同じデバイスをスピンアップし、各デバイスでテストのサブセットを実行します。テストケースをシャーディングすると、デバイスごとに複数のテストを実行できるということです。ただし、シャーディングされていないテストケースでは常にデバイスごとに 1 つのテストが実行されます。Test Lab のコンセプトについては、主なコンセプトをご覧ください。

Firebase コンソールでテストのシャーディングを有効にする手順は次のとおりです。

  1. インストルメンテーション テストの設定で、[詳細オプション] をクリックします。

  2. [シャーディング] セクションで、実行するシャードの数を入力します。

テストシャードに対する課金

Test Lab は、AndroidJUnitRunner の組み込みシャーディング メカニズムを利用してシャードを実装します。空のシャード（テストケースが割り当てられていないシャード）を起動して課金が発生することのないように、作成するシャードの数はテストケースの合計数より少なくしてください。一般に、各テストケースの実行にかかる時間に応じて、シャードごとに 2～10 個のテストケースを割り当てることをおすすめします。

課金の詳細については、使用量、割り当て、課金をご覧ください。