テストコーパスが大きい場合や実行時間が長い場合は、複数のデバイスにテストを分割、つまりシャーディングできます。
テストランナーがシャーディングをサポートするためには、前提条件を満たす必要があります。
主要なテストランナーはすでにシャーディングをサポートしているため、追加の作業は必要ありません。インストゥルメンテーション テスト、ホスト駆動によるテスト、GTest はすでにシャーディングをサポートしています。
Tradefed では、ローカル型と分散型の 2 つの型のシャーディングがサポートされています。この 2 つには共通点があります。このページでは共通する特徴とそれぞれに固有の特徴を説明します。
共通のプロパティ
ローカル型と分散型のフォームは共に、テストランナーのプロパティが同じであることを想定しています。シャーディングは独立的かつ決定論的である必要があります。どちらのシャーディングでも、最初のステップは、テストの完全な順序付きリストを作成し、複数のグループやシャードに分割することです。
シャーディングの形式の主な違いは、テストの実行方法です。 詳しくは以下の各セクションをご覧ください。
ローカル型シャーディング
ローカル型シャーディングは、シャーディングされた呼び出しの実行に関係するすべてのデバイスが同じ物理ホストに接続されていることを意味します。
実行
ローカル型シャーディングでは、実行する必要があるテストのプールを作成し、各デバイスが利用可能になったとき（直前のテストが完了したとき）にテストをポーリングさせることで、同じホストに接続されているすべてのデバイスを利用します。これにより、デバイスの使用を最適化できます。これは、動的シャーディングとも呼ばれます。
オプション
--shard-count XX
分散型シャーディング
分散型シャーディングは、シャーディングされた呼び出しの実行に関係するすべてのデバイスはどこに存在していてもよく、異なる物理ホストにも接続できることを意味します。
実行
分散型シャーディングはテストのリスト作成時に実行され、各シャードのコンテンツは現在リクエストされているシャードのみを実行します。そのため、分散型シャードは最初に同じリストを作成し、次にそのリストの相互に排他的なサブセットを実行します。これにより、すべてのテストが実行されます。
この形式の最も重要な特徴は、シャード同士は相互に認識せず、それぞれ独立して失敗することがあるという点です。
最も重大な欠点は、各シャードで各テストのランタイムを事前に予測できないため、シャードの長さが必ずしもバランスよく調整されない点です。分散は、各シャードのテストケース数がほぼ同じになるように行われます。
オプション
--shard-count XX --shard-index XX
トークンのシャーディング
トークンのシャーディングはローカル型シャーディングでのみ使用できます。ローカル型シャーディング以外のユースケースでは、このフラグは機能しません。シャーディングで使用されるデバイスの中には、SIM カードなど、他のデバイスにはない特別なリソースを持つものがあります。テストの中には、特別なリソースが利用可能な場合にのみ動作し、そうでない場合には失敗するものがあります。
トークンのシャーディングは、そのようなユースケースに対するソリューションとなります。テスト モジュールは、必要とする特別なリソースを AndroidTest.xml で宣言できます。Tradefed はそのリソースを持つデバイスにテストをルーティングします。
XML 構成
<option name="config-descriptor:metadata" key="token" value="SIM_CARD" />
トークンの value は、Tradefed の TokenProperty と一致し、TokenProviderHelper のハンドラに関連付けられています。
これにより、テストを適切に実行できるデバイスに対してテスト モジュールを実行できるようになります。
テストを実行できるデバイスがない場合
リソースがテスト モジュールに一致するデバイスがない場合、テスト モジュールを正常に実行できないため、そのテスト モジュールは失敗し、スキップされます。
たとえば、テスト モジュールが SIM カードの実行をリクエストしても、SIM カードを持つデバイスがない場合、そのテスト モジュールは失敗します。
実装
この機能フラグを Tradefed のメインのコマンドラインに渡します。
--enable-token-sharding