高度なテスト設定

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

基本的なテスト構成を設定して実行する方法については、Android Studio でのテストコマンドラインからのテストで説明しています。ただし、アプリとそのテスト要件が高度になるほど、テスト構成の調整が必要になります。たとえば、次を行う場合、テストの詳細設定が必要になります。

  • 特定のビルド バリアントに対してのみインストルメンテーション テストを実行するか、そのマニフェスト設定をオーバーライドする。
  • テストを実行するビルドタイプを変更するか、その Gradle オプションを設定する。
  • インストルメンテーション テストを独自のテスト モジュールに抽出する。

このページでは、デフォルト設定が目前のユースケースに適していない場合にテストを設定する方法をいくつか説明しています。

ビルド バリアントに応じたインストルメンテーション テストを作成する

一意のソースセットを持つビルド バリアントがプロジェクトに含まれている場合は、そのソースセットに対応するインストルメンテーション テストを含めることをおすすめします。これにより、テストコードを適切に分類して、特定のビルド バリアントに適用されるテストのみを実行できます。

インストルメンテーション テストを、src/androidTestVariantName にある独自のソースセットに配置することで、ビルド バリアントにリンクすることができます。

src/androidTest/ ソースセット内のインストルメンテーション テストは、すべてのビルド バリアントによって共有されます。アプリの「MyFlavor」バリアント用のテスト APK をビルドすると、Gradle は src/androidTest/ ソースセットと src/androidTestMyFlavor/ ソースセットを結合します。

Android Studio でビルド バリアントに応じたテスト ソースセットを追加する手順は次のとおりです。

  1. 左側の [Project] ウィンドウでプルダウン メニューをクリックし、[Project] ビューを選択します。
  2. 適切なモジュール フォルダ内で src フォルダを右クリックし、[New] > [Directory] をクリックします。
  3. ディレクトリ名として「androidTestVariantName」と入力します。たとえば、ビルド バリアントが「MyFlavor」の場合、ディレクトリ名を「androidTestMyFlavor」とします。次に、[OK] をクリックします。
  4. 新しいディレクトリを右クリックして、[New] > [Directory] をクリックします。
  5. ディレクトリ名として「java」と入力し、[OK] をクリックします。

これで、新しいテストの追加手順に沿って、この新しいソースセットにテストを追加できるようになりました。[Choose Destination Directory] ダイアログが表示されたら、新たに作成したバリアント用テスト ソースセットを選択します。

次の表に、インストルメンテーション テストのファイルがソースセット内にどのように配置されるかの例を示します。ソースセットはアプリのコード ソースセットに対応しています。

表 1. アプリのソースコードと、対応するインストルメンテーション テストのファイル

アプリクラスのパス 対応するインストルメンテーション テストクラスのパス
src/main/java/Foo.java src/androidTest/java/AndroidFooTest.java
src/myFlavor/java/Foo.java src/androidTestMyFlavor/java/AndroidFooTest.java

アプリ ソースセットの場合と同様に、Gradle のビルドでは、異なるテスト ソースセットのファイルをマージおよびオーバーライドします。この場合、androidTestMyFlavor ソースセット内の AndroidFooTest.java ファイルは、androidTest ソースセット内のバージョンをオーバーライドします。プロダクト フレーバーのソースセットがメインのソースセットよりも優先されるためです。ソースセットがどのようにマージされるかについては、ビルドを設定するをご覧ください。

インストルメンテーション テスト用のマニフェストを設定する

インストルメンテーション テストは、独自の AndroidManifest.xml ファイルとともに個別の APK に組み込まれます。Gradle がテスト APK をビルドすると、自動的に AndroidManifest.xml ファイルが生成され、マニフェストに <instrumentation> ノードが設定されます。Gradle によりこのノードが設定されるのは、targetPackage プロパティがテスト対象アプリの正しいパッケージ名を指すようにするためでもあります。このノードの他の設定を変更するには、テスト ソースセット内に別のマニフェスト ファイルを作成するか、下記のコードサンプルに示すように、モジュール レベルの build.gradle ファイルを設定します。オプションの一覧については、BaseFlavor API リファレンスをご覧ください。

android {

    ...

    // Each product flavor you configure can override properties in the
    // defaultConfig {} block. To learn more, go to Configure product flavors.

    defaultConfig {

        ...

        // Specifies the application ID for the test APK.
        testApplicationId = "com.test.foo"

        // Specifies the fully-qualified class name of the test instrumentation
        // runner.
        testInstrumentationRunner = "android.test.InstrumentationTestRunner"

        // If set to true, enables the instrumentation class to start and stop profiling.
        // If set to false (default), profiling occurs the entire time the instrumentation
        // class is running.
        testHandleProfiling = true

        // If set to true, indicates that the Android system should run the instrumentation
        // class as a functional test. The default value is false.
        testFunctionalTest = true

    }
}

テストのビルドタイプを変更する

デフォルトでは、すべてのインストルメンテーション テストは debug ビルドタイプに対して実行されます。テスト対象を別のビルドタイプに変更するには、モジュール レベルの build.gradle ファイルの testBuildType プロパティを使用します。たとえば、staging ビルドタイプに対してテストを実行するには、次のスニペットのようにファイルを編集します。

android {

    ...

    testBuildType "staging"

}

Gradle テスト オプションを設定する

Android Gradle プラグインを使用すると、テストのすべてまたは一部のオプションを指定できます。モジュール レベルの build.gradle ファイルで、testOptions{} ブロックを使用して、Gradle が実行するすべてのテストに適用されるオプションを指定します。

Groovy

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        // Changes the directory where Gradle saves test reports. By default,
        // Gradle saves test reports in the
        // path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default,
        // Gradle saves test results in the
        // path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        resultsDir "$rootDir/test-results"
    }
}

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        // Changes the directory where Gradle saves test reports. By default,
        // Gradle saves test reports in the
        // path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default,
        // Gradle saves test results in the
        // path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the
        // current project.
        resultsDir = "$rootDir/test-results"
    }
}

ローカル単体テストのみのオプションを指定するには、testOptions{} 内に unitTests{} ブロックを設定します。

Groovy

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            // By default, local unit tests throw an exception any time the code
            // you are testing tries to access Android platform APIs (unless you
            /// mock Android dependencies yourself or with a testing framework like Mockito).
            // However, you can enable the following property so that the test
            // returns either null or zero when accessing platform APIs, rather
            // than throwing an exception.
            returnDefaultValues true

            // Encapsulates options for controlling how Gradle executes local
            // unit tests. For a list of all the options you can specify, read
            // Gradle's reference documentation.
            all {
                // Sets JVM argument(s) for the test JVM(s).
                jvmArgs '-XX:MaxPermSize=256m'

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            // By default, local unit tests throw an exception any time the code
            // you are testing tries to access Android platform APIs (unless you
            /// mock Android dependencies yourself or with a testing framework like Mockito).
            // However, you can enable the following property so that the test
            // returns either null or zero when accessing platform APIs, rather
            // than throwing an exception.
            returnDefaultValues = true

            // Encapsulates options for controlling how Gradle executes local
            // unit tests. For a list of all the options you can specify, read
            // Gradle's reference documentation.
            all {
                // Sets JVM argument(s) for the test JVM(s).
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

インストルメンテーション テスト専用のテスト モジュールを使用する

インストルメンテーション テスト専用のモジュールを作成して残りのコードをテストから分離する場合は、別個のテスト モジュールを作成し、ライブラリ モジュールの場合と同じようにビルドを構成します。テスト モジュールを作成する手順は次のとおりです。

  1. ライブラリ モジュールを作成します。
  2. モジュール レベルの build.gradle ファイルで、com.android.library の代わりに com.android.test プラグインを適用します。
  3. プロジェクトの同期アイコン をクリックしてプロジェクトを同期します。

テスト モジュールを作成したら、テストコードをメインまたはバリアントのソースセット(src/main/javasrc/variant/java など)に追加できます。アプリ モジュールで複数のプロダクト フレーバーを定義している場合は、テスト モジュールにそれらのフレーバーを再作成できます。その場合、テスト モジュールはバリアント認識型の依存関係管理を使用して、ターゲット モジュール内の一致するフレーバーのテストを試みます。

デフォルトでは、テスト モジュールに含まれておりテストされるのはデバッグ バリアントのみです。ただし、テスト済みのアプリ プロジェクトに合わせて、新しいビルドタイプを作成できます。テスト モジュールでデバッグ以外のビルドタイプをテストするには、次に示すように、VariantFilter を使用してテスト プロジェクト内のデバッグ バリアントを無効にします。

Groovy

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

テスト モジュールのターゲットをアプリの特定のフレーバーまたはビルドタイプのみにする場合は、matchingFallbacks プロパティを使用して、テストするバリアントのみをターゲットにできます。これにより、テスト モジュール自体でそれらのバリアントを設定する必要もなくなります。