このページでは、Tradefedで新しいテストランナーを作成する方法について説明します。
バックグラウンド
Tradefedアーキテクチャでのテストランナーの位置について知りたい場合は、「テストランナーの構造」を参照してください。
これは、新しいテストランナーを作成するための前提条件ではありません。テストランナーは単独で作成できます。
最低限：インターフェースの実装
Tradefedテストランナーとしての資格を得るには、最低限、 IRemoteTestインターフェイス、より具体的にはrun(TestInformation testInfo, ITestInvocationListener listener)メソッドを実装する必要があります。
このメソッドは、Java Runnableと同様に、テストランナーを使用するときにハーネスによって呼び出されるメソッドです。
そのメソッドのすべての部分は、テストランナー実行の一部と見なされます。
テストランナーからの結果の報告
基本インターフェースのrunメソッドは、タイプITestInvocationListenerのリスナーオブジェクトへのアクセスを提供します。このオブジェクトは、テストランナーからハーネスに構造化された結果を報告するための鍵です。
構造化された結果を報告することにより、テストランナーには次のプロパティがあります。
- 実行されたすべてのテスト、それらがかかった時間、およびそれらが個別に合格したか、失敗したか、または他のいくつかの状態の適切なリストを報告します。
- 該当する場合は、テストに関連するメトリックを報告します。たとえば、インストール時のメトリックなどです。
- 結果や指標の表示など、ほとんどのインフラストラクチャツールに適合します。
- 実行のより詳細なトレースがあるため、通常はデバッグが容易です。
とはいえ、構造化された結果の報告はオプションです。テストランナーは、実際の実行の詳細なしで、実行全体の状態をPASSEDまたはFAILEDとして評価したい場合があります。
注：一連のイベントに従うランナーを実装することはより困難ですが、上記の利点を考慮して実装することをお勧めします。
次のイベントをリスナーで呼び出して、実行の現在の進行状況をハーネスに通知できます。
- testRunStarted：相互に関連するテストケースのグループの開始を通知します。
- testStarted：テストケースの開始を通知します。
- testFailed / testIgnored：進行中のテストケースの状態の変化を通知します。状態が変化しないテストケースは合格と見なされます。
- testEnded：テストケースの終了を通知します。
- testRunFailed：テストケース実行のグループの全体的なステータスが失敗であることを通知します。テストの実行は、実行が何を期待していたかに応じて、テストケースの結果とは関係なく、合格または不合格になる可能性があります。たとえば、複数のテストケースを実行しているバイナリは、すべての合格テストケースを報告できますが、エラー終了コードが含まれます（何らかの理由で：ファイルのリークなど）。
- testRunEnded：テストケースのグループの終わりを通知します。
コールバックの適切な順序を維持および保証するのは、テストランナーの実装者の責任です。たとえば、 finally句を使用して例外が発生した場合に、 testRunEndedが呼び出されるようにします。
テストケースのコールバック（ testStarted 、 testEndedなど）はオプションです。テスト実行は、テストケースなしで発生する可能性があります。
このイベントの構造は、典型的なJUnit構造から着想を得ていることに気付くかもしれません。これは、開発者が通常知っている基本的なものに近づけることを目的としています。
テストランナーからのレポートログ
独自のTradefedテストクラスまたはランナーを作成している場合は、 ITestInvocationListenerを実装し、 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オブジェクトにアクセスできます。詳細については、構成オブジェクトの説明を参照してください。
テストランナーの実装では、 IConfigurationオブジェクトを受け取るためにIConfigurationReceiverを実装する必要があります。
柔軟なテストランナー
テストランナーは、テストをきめ細かく制御できる場合、テストを柔軟に実行する方法を提供できます。たとえば、JUnitテストランナーは、各単体テストを個別に実行できます。
これにより、より大きなハーネスとインフラストラクチャがその微調整を活用し、ユーザーがフィルタリングを介してテストランナーを部分的に実行できるようになります。
フィルタリングのサポートは、 ITestFilterReceiverインターフェイスで説明されています。これにより、実行する必要があるテストと実行しないテストのincludeフィルターとexcludeフィルターのセットを受け取ることができます。
私たちの慣例では、テストは1つ以上の包含フィルターに一致し、どの除外フィルターにも一致しない場合に実行されます。インクルードフィルターが指定されていない場合は、どのエクスクルードフィルターとも一致しない限り、すべてのテストを実行する必要があります。
注：テストランナーは、より大規模なインフラストラクチャで大きな付加価値を提供するため、このフィルタリングをサポートする方法で作成することをお勧めします。しかし、場合によってはそうすることができないことを理解しています。