はじめに

メインのプロジェクト ディレクトリで Jtest の Gradle 用タスクを実行することで、解析やテストを実行できます。マルチモジュール プロジェクトをテストする場合を除いて、解析の前に必ずテスト対象プロジェクトをビルドする必要はありません。マルチモジュール プロジェクトの場合は、コマンド ラインに build または assemble タスクを追加して、解析を実行する前にコンパイルすることを推奨します。そうすると、Jtest はローカル リポジトリの成果物を使用できるため、コードのテストおよび解析にかかる時間を短くできます。

また、マルチモジュール プロジェクトの場合、ルート プロジェクトに対してタスクを実行する必要があります。そうすると、Jtest はすべてのサブプロジェクトもテストまたは解析します。特定のサブプロジェクトをテストするには、ルート プロジェクトに対して Jtest タスク (jtest、jtest-agent、または affectedTests) を実行し、個々のサブプロジェクトに対して Gradle の test タスクを実行します。詳細については「単体テスト テストの実行とカバレッジの収集」を参照してください。

静的解析の実行

コードに対して静的解析を実行するには、次の操作を行います。

  1. Jtest Plugin for Gradle がセットアップ済みであることを確認します (「Jtest Plugin for Gradle の設定」を参照)。

  2. jtest タスクを実行します。コマンドは次のようになります。

    gradle jtest -I PATH/TO/JTEST/integration/gradle/init.gradle

    Jtest Plugin for Gradle は、.json ファイルから必要なビルド データを収集し、指定したテスト コンフィギュレーションに従ってコードを解析します。

  3. 解析結果を参照します (「結果の参照」を参照)。

(info) デフォルトでは、テスト ソースは解析から除外されます。テスト コードを解析対象にするには、excludeTestSources オプションを無効にします。「Gradle 用 Jtest ゴール リファレンス」を参照してください。

Android プロジェクトに対する静的解析の実行

Jtest は専用の Gradle タスクを使用して Android プロジェクトに対して静的解析コンフィギュレーションを実行できます。特定のアプリケーション バリアント (ビルド タイプおよび製品フレーバー) に対して静的解析を実行できます。実行ごとに 1 つのアプリケーション バリアントだけがサポートされます。複数のアプリケーション バリアントに対して静的解析を実行するには、バリアントごとに実行する必要があります。

静的解析を実行するには、次のタスクを実行します。

jtest[APPLICATION VARIANT NAME] -  APPLICATION VARIANT NAME はテスト コンフィギュレーションを実行するアプリケーション バリアントの名前です。

Android Gradle ビルドのすべてのアプリケーション バリアントで実行可能なタスクの一覧を表示するには、次のコマンドを使用します。

gradlew tasks –I [JTEST_HOME/integration/gradle/init.gradle]

例:

次の例は、“Debug” ビルド タイプおよび “Demo” という名前のフレーバー (アプリケーション バリアント名は "DemoDebug") に対して "Android Guidelines" テスト コンフィギュレーションを実行するコマンド ラインです。

gradlew installDemoDebug jtestDemoDebug –Djtest.config=”builtin://Android Guidelines”

単体テスト テストの実行とカバレッジの収集

Jtest レポートに単体テストの結果を含めるには、jtest タスクと jtest-agent タスク、および単体テスト用のビルトイン テスト コンフィギュレーション Unit Tests を使用してテストを実行します。

  1. Jtest Plugin for Gradle がセットアップ済みであることを確認します (「Jtest Plugin for Gradle の設定」を参照)。

  2. 次の順序で Gradle タスクを実行します:
    - jtest-agent タスク
    - test (または build) タスクで単体テストを実行します。
    - jtest タスク
      コマンドは次のようになります。

    gradle clean jtest-agent test jtest -Djtest.config="builtin://Unit Tests"

デフォルトでは、Jtest は実行されたテストのカバレッジ データを収集します。カバレッジの収集を無効化するには、jtest.coverage.skip オプションを有効にします (詳細は「Gradle 用 Jtest タスク リファレンス」を参照)。

マルチモジュール プロジェクトをテストする場合、デフォルトでは、Jtest はルート プロジェクトのすべてのサブプロジェクトのカバレッジ情報を収集します。特定のサブプロジェクトのカバレッジを収集するには、テストするサブプロジェクトに対して Gradle の test タスクを実行するようコマンド ラインを変更します。コマンドは次のようになります。

gradle clean jtest-agent subproject1:test subproject2:test jtest -Djtest.config="builtin://Unit Tests"

(info) org.junit.Assume (JUnit 4) または org.junit.jupiter.api.Assumptions (JUnit 5) クラスからメソッドを呼び出してテストをスキップすると、Jtest はメソッドが呼び出される前に実行されたコード行のカバレッジを収集します。このカバレッジ情報は、カバレッジ レポートのテストに関連付けられていません。

Jtest は、-parallel または --parallel オプションで有効化された Gradle マルチモジュール プロジェクトのパラレル ビルドのテスト カバレッジを収集します。詳細については、https://docs.gradle.org/current/userguide/performance.html#parallel_execution を参照してください。例:

gradle -parallel clean jtest-agent test jtest -Djtest.config="builtin://Unit Tests"

Android プロジェクトのアプリケーション カバレッジの収集 

Jetst は、Gradle ビルドに基づいて、Android プロジェクトのローカルな単体テストからカバレッジを収集できます。Jtest は Java および Kotlin で作成された単体テストをサポートします。特定のアプリケーション バリアント (ビルド タイプおよび製品フレーバー) のカバレッジを収集できます。実行ごとに 1 つのアプリケーション バリアントだけがサポートされます。複数のアプリケーション バリアントのカバレッジを収集するには、バリアントごとに収集する必要があります。

Jtest Agent をアタッチしてカバレッジを収集するには、次のタスクを実行する必要があります。

jtestAgent[APPLICATION VARIANT NAME] -  APPLICATION VARIANT NAME はカバレッジを収集するアプリケーション バリアントの名前です。

jtest[APPLICATION VARIANT NAME]  -   APPLICATION VARIANT NAME  はテスト コンフィギュレーションを実行するアプリケーション バリアントの名前です。

Android Gradle ビルドで利用可能なタスクの一覧を表示するには、次のコマンドを使用します。

gradlew tasks –I[JTEST_HOME/integration/gradle/init.gradle]

例:

次の例は、“Debug” ビルド タイプおよび “Demo” という名前のフレーバー (アプリケーション バリアント名は "DemoDebug") のローカルな単体テストからカバレッジを収集するコマンド ラインです。

gradlew compileDemoDebugUnitTestSources jtestAgentDemoDebug testDemoDebugUnitTest jtestDemoDebug –Djtest.config=”builtin://Unit Tests”

 制限事項:

  • インストゥルメントされたテスト (エミューレーションされたターゲット デバイスまたは物理的ターゲット デバイスで実行されるテスト) からのカバレッジ収集はサポートされていません。
  • Kotlin テストからの結果の収集および Kotlin クラスからのカバレッジの収集は、IDE ではサポートされていません。CLI でだけサポートされています。 
  • カバレッジの収集とレポートは、1 度に 1 つのアプリケーション バリアントでだけサポートされます。

アプリケーション カバレッジの収集

Jtest のカバレッジ エージェントを使用すると、実行中のアプリケーションでの手動テストまたは自動テスト実行時にカバレッジ データを収集できます。Jtest でのアプリケーション カバレッジの収集については「アプリケーション カバレッジ」を参照してください。

テスト影響分析

Jtest Plugin for Gradle の機能を拡張してテスト影響分析を使用することができます。テスト影響分析を行うと、変更の影響を受けるテストだけを識別して再実行できるため、影響を受けない多数のテストを実行するのに必要な時間や手間を省くことができます。プロジェクトのテスト影響分析を行うには、以下が必要です。

  1. テスト影響分析プラグインを設定します。
  2. affectedTests タスクを実行します。

Gradle ビルド スクリプトを変更する必要はありません。

前提条件

  • Jtest 10.4.1 以上
  • Gradle 3.3 以上
  • JUnit 4 または 5

(info) テスト影響分析を実行するには、さらにメモリが必要になります。Gradle ビルドに割り当てるメモリを増やすことを推奨します。

Test Impact Analysis Plugin との統合

Jtest に付属の init.gradle スクリプトを使用すると、Gradle のビルド スクリプトを変更せずにテスト影響分析プラグインと Gradle を統合できます。プラグインと Gradle を統合するには、-I オプションを使用してコマンド ラインに init.gradle スクリプトの場所を渡します。

gradle affectedTests test -I PATH/TO/JTEST/integration/gradle/init.gradle

プラグインの設定

テスト影響分析プラグインのプロパティを設定することで、POM ファイルまたはコマンド ラインからプロジェクトのテスト影響分析をカスタマイズできます。最低でも、実行時に Jtest が生成する以下のファイルへのパスを指定する必要があります。

  • coverage.xml  

  • report.xml

利用可能なオプションの一覧については「Gradle 用 Jtest タスク リファレンス」を参照してください。

ビルド スクリプトでの設定

ビルド スクリプトで設定を宣言する際にプロパティを指定します。

build.gradle
affectedTests {
    referenceCoverageFile = 'path/to/coverage.xml'
    referenceReportFile = 'path/to/report.xml'
    runFailedTests = false
    runModifiedTests = true
    jtestHome = 'path/to/jtest'
    settings = 'path/to/jtestcli.properties'
}

コマンド ラインでの設定

コマンド ラインでテスト影響分析をカスタマイズするには、-D スイッチを使用してプラグイン プロパティを渡します。プロパティには "jtest" 接頭辞を付ける必要があります (「Gradle 用 Jtest タスク リファレンス」を参照)。コマンドは次のようになります。

コマンド ライン
gradle affectedTests test -I PATH/TO/JTEST/integration/gradle/init.gradle -Djtest.referenceCoverageFile="path/to/coverage.xml" -Djtest.referenceReportFile="path/to/report.xml" -Djtest.runFailedTests=false -Djtest.runModifiedTests=true -Djtest.home="path/to/jtest" -Djtest.settings="jtestcli.properties"

affectedTest タスクの設定と実行

これ以上の追加の設定なしでコマンド ラインから affectedTests タスクを実行できます。必ず test タスクの前に実行します。コマンドは次のようになります。

コマンド ライン
gradle clean affectedTests test -I PATH/TO/JTEST/integration/gradle/init.gradle

または、以下のように実行することもできます。

  1. build.gradle スクリプトでタスクの実行を設定します。

    build.gradle
    test.dependsOn affectedTests

  2. Gradle の test タスクを実行します – 自動的に affectedTests タスクが実行されます。

    コマンド ライン
    gradle test -I PATH/TO/JTEST/integration/gradle/init.gradle

マルチモジュール プロジェクトの特定のサブプロジェクトに対して affectedTests タスクを実行するには、テストするサブプロジェクトに対して Gradle の test タスクを実行するようコマンド ラインを変更します。コマンドは次のようになります。

gradle clean affectedTests subproject1:test subproject2:test -Djtest.referenceCoverageFile=tia/coverage.xml -Djtest.referenceReportFile=tia/report.xml -I path_jtest\integration\gradle\init.gradle

ネストされたテストの処理

Gradle にはネストされたテストの処理に関する制限があり、テスト影響分析が別のテストにネストされたテストをどのように再実行するかに影響を与えます。runModifiedTests オプションが true に設定されている場合、ネストされたテストは、コード変更の影響を受けなくても常に再実行されます。

この Gradle の問題は、Gradle 6.0.1 以前のバージョンで再現されています。

テスト スイートの再実行

テスト影響分析は、テスト スイート内の少なくとも 1 つのテストがコードの変更の影響を受ける場合、テスト スイート全体を再実行します。そのため、影響を受けるテストと同じテスト スイートに含まれている場合、影響を受けないテストも実行される場合があることに注意してください。

  • No labels

Need assistance? Visit our support page