Tradefed テストランナーを作成する

このページでは、Tradefed で新しいテストランナーを作成する方法について説明します。

背景

Tradefed アーキテクチャでのテストランナーの場所については、テストランナーの構造をご覧ください。

これは、新しいテストランナーを作成するための前提条件ではありません。テストランナーは単独で作成できます。

必要最小限: インターフェースの実装

Tradefed テストランナーとして適格となる必要最小限の方法は、IRemoteTest インターフェース、具体的には run(TestInformation testInfo, ITestInvocationListener listener) メソッドを実装することです。

このメソッドは、Java Runnable と同様、テストランナーの使用時にハーネスによって呼び出されます。

このメソッドのあらゆる部分がテストランナー実行の一部と見なされます。

テストランナーからの結果の報告

ベース インターフェースの run メソッドは、ITestInvocationListener 型のリスナー オブジェクトへのアクセスを許可します。このオブジェクトは、テストランナーからハーネスに構造化された結果を報告するために重要です。

構造化された結果を報告することで、テストランナーには次の特性があります。

  • 実行されたすべてのテストの適切なリスト、テストにかかった時間、個々のテストに合格したか、不合格になったか、またはその他の状態を報告します。
  • 該当する場合はテストに関連付けられた指標(インストール時の指標など)を報告します。
  • 表示結果や指標など、ほとんどのインフラストラクチャ ツールに適します。
  • 通常は、実行のトレースがより詳細であるため、デバッグが容易になります。

とは言え、構造化された結果の報告はオプションです。テストランナーは、実際の実行の詳細なしに、実行全体の状態を単に合格または不合格として評価できます。

次のイベントをリスナーで呼び出して、現在の実行の進行状況をハーネスに通知できます。

  • testRunStarted: 互いに関連するテストケース グループの始まりを通知します。
    • testStarted: 開始したテストケースの始まりを通知します。
    • testFailed/testIgnored: 進行中のテストケースの状態変化を通知します。状態の変化がないテストケースは合格と見なされます。
    • testEnded: テストケースの終わりを通知します。
  • testRunFailed: テストケース実行グループの全体的なステータスが不合格であることを通知します。テスト実行は、実行の想定内容に応じて、テストケースの結果と関係なく、合格または不合格になります。たとえば複数のテストケースを実行しているバイナリが、すべての合格テストケースを(ファイルのリークなど、なんらかの理由で)エラー終了コードとともに報告することがあります。
  • testRunEnded: テストケース グループの終わりを通知します。

コールバックの適切な順序の維持と確保は、テストランナー実装者の責任です。たとえば、finally 句を使用して例外が発生した場合に testRunEnded が呼び出されるようにします。

テストケースのコールバック(testStartedtestEnded など)はオプションです。テストは、テストケースなしでも実行できます。

イベントのこの構造が典型的な JUnit 構造を参考にしていることに気付くかもしれません。これは、デベロッパーが通常知っている基本的なものに近づけるためです。

テストランナーからのログの報告

独自の Tradefed テストクラスまたはランナーを作成する場合は、IRemoteTest を実装し、run() メソッドで ITestInvocationListener を取得します。このリスナーを使用して、次のようにファイルをログに記録できます。

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

デバイスでのテスト

上記の最小限のインターフェースを使用すると、分離され、特定のリソースを必要としない、非常にシンプルなテスト(Java の単体テストなど)を実行できます。

デバイステストの次のステップに進むテスト作成者には、下記のインターフェースが必要です。

  • IDeviceTest を使用すると、テスト中のデバイスを表す ITestDevice オブジェクトを受け取れます。情報をやり取りする API が用意されています。
  • IBuildReceiver: ビルド プロバイダ ステップで作成された IBuildInfo オブジェクトをテストに取り込むことができます。テストのセットアップに関連するすべての情報とアーティファクトが含まれています。

テストランナーは通常、実行に関連するアーティファクト(追加ファイルなど)を取得し、実行中に対象となるテスト中のデバイスを取得するために、このようなインターフェースに関心を持ちます。

複数のデバイスでのテスト

Tradefed は複数のデバイスによるテストの同時実行をサポートしています。これは、電話や時計のペア設定など、外部操作が必要なコンポーネントをテストする場合に便利です。

複数のデバイスを使用できるテストランナーを作成するには、IMultiDeviceTest を実装する必要があります。これにより、ITestDevice から IBuildInfo へのマップを受け取れます。これには、デバイス表現と関連ビルド情報の完全なリストが含まれます。

インターフェースからのセッターは常に run メソッドの前に呼び出されるため、run が呼び出されると構造が利用可能になるという仮定をすると安全です。

設定を認識したテスト

テストランナー実装によっては、適切に機能するために、全体的な設定に関する情報(呼び出しに関するメタデータや、以前どの target_preparer が実行されたかなど)が必要になることがあります。

これを実現するために、テストランナーは、一部となっている、また実行される、IConfiguration オブジェクトにアクセスできます。詳細については、Configuration オブジェクトの説明をご覧ください。

テストランナー実装では、IConfiguration オブジェクトを受け取るために IConfigurationReceiver を実装する必要があります。

柔軟なテストランナー

テストランナーは、細かく制御できる場合、テストを柔軟に実行できます。たとえば JUnit テストランナーは、各単体テストを個別に実行できます。

これにより、大規模なハーネスとインフラストラクチャで細かい制御を活用でき、ユーザーはフィルタリングによってテストランナーを部分的に実行できます。

フィルタリングのサポートについては、ITestFilterReceiver インターフェースで説明していますが、これにより、実行すべきテストと実行すべきでないテストについて、include フィルタと exclude フィルタのセットを受け取れます。

テストは、1 つ以上の include フィルタと一致し、かつ、いずれの exclude フィルタとも一致しない場合に実行されます。include フィルタが指定されていない場合は、いずれの exclude フィルタとも一致しない限り、すべてのテストが実行されます。