Espresso アイドリング リソース

アイドリング リソースは、結果が影響を受ける非同期オペレーションを表します。 UI テストにおける後続のオペレーションです。アイドル状態のリソースを Espresso を使用すると、こうした非同期オペレーションをより確実に検証できます。 説明します。

アイドリング リソースが必要になるケースの特定

Espresso には洗練された 同期機能が用意されています。この ただし、フレームワークの特性は、POST リクエストを送信しますが、 MessageQueue に対するメッセージ(次のサブクラスなど)が コンテンツを画面に描画している View

Espresso は、次のような他の非同期処理を認識しないためです。 バックグラウンド スレッドで実行されている場合、Espresso はその同期を提供できない 保証されませんEspresso がアプリの状態を認識できるようにするには、 各オペレーションをアイドリング リソースとして登録する必要があります。

アプリのテスト結果のテスト時にアイドリング リソースを使用しない場合、 非同期の処理を実行する場合は、 テストを改善するための不正な回避策を講じる信頼性:

  • Thread.sleep() の呼び出しの追加。ユーザーが テストに人為的な遅延を追加すると、テストスイートが テストは失敗する可能性があります。 ダウンロードされます。また、こうした遅延はスケーリングがうまくいかず、 時間のかかる非同期処理を今後のリリースで行うことになります。
  • 再試行ラッパーの実装。ループを使用して、 タイムアウトが発生するまでアプリが非同期処理を実行し続けている場合。たとえ テストの最大再試行回数を指定します。再実行のたびに システムリソース、特に CPU です。
  • CountDownLatch のインスタンスを使用する。これは、 1 つ以上のスレッドが、特定の数のオペレーションが完了するまで待機することを許可する 完了していないことになりますこれらのオブジェクトには、 タイムアウトの長さ。そうしないと、アプリが無期限にブロックされる可能性があります。ラッチ コードが不必要に複雑になり メンテナンスが困難になります

Espresso を使用すると、このような信頼できない回避策をテストやソリューションから削除できます。 アプリの非同期処理をアイドリング リソースとして登録してください。

一般的なユースケース

テストで次の例のようなオペレーションを実行する場合は、 次のようなアイドリング リソースの使用を検討してください。

  • インターネットやローカル データソースからのデータの読み込み
  • データベースやコールバックとの接続の確立
  • サービスの管理(システム サービスまたはインスタンスのインスタンスを使用) IntentService
  • ビットマップ変換などの複雑なビジネス ロジックの実行

アイドル状態のリソースを登録することは、これらのオペレーションが テストで検証する UI を更新します。

アイドリング リソースの実装例

アイドリング リソースの実装例をいくつか次のリストに示します。 アプリに統合できる機能を紹介します。

CountingIdlingResource
アクティブなタスクのカウンタを保持します。カウンタがゼロの場合、関連付けられている アイドル状態とみなされます。この機能は Semaphore。ほとんどの場合、この実装は テスト中にアプリの非同期処理を管理するのに十分です。
UriIdlingResource
似ている CountingIdlingResource, 特定の期間、カウンタがゼロになっている必要が アイドル状態とみなされます。この追加の待機時間が リクエストしているため、スレッド内のアプリが 前のリクエストに対するレスポンスを受け取った直後にリクエストを実行します。
IdlingThreadPoolExecutor
ThreadPoolExecutor のカスタム実装 作成されたスレッド内で実行中のタスクの合計数を追跡する 構成されます。このクラスでは、 CountingIdlingResource~ アクティブなタスクのカウンタを維持します。
IdlingScheduledThreadPoolExecutor
カスタム実装 ScheduledThreadPoolExecutor。Google Kubernetes Engine は オンプレミスと同じく IdlingThreadPoolExecutor タスクやタスクを追跡したり、 スケジュールされます
で確認できます。

独自のアイドリング リソースの作成

アプリのテストでアイドリング リソースを使用する際、必要に応じて、 カスタムのリソース管理またはロギングに 役立ちますその場合、実装には 前のセクションで説明した方法では十分でない場合があります。その場合は、 これらのアイドリング リソース実装のいずれかを拡張するか、独自に作成します。

独自のアイドリング リソース機能を実装する場合は、次のベスト プラクティスを遵守してください。 ベスト プラクティスを実践します。

アイドル状態の確認の部分で、アイドル状態への遷移を呼び出さない。
アプリがアイドル状態になったら、 onTransitionToIdle() あらゆる実装の isIdleNow()。これにより、 Espresso は、特定の依存関係があるかどうかを判定するための アイドル状態になります。

次のコード スニペットは、この推奨事項について示しています。

Kotlin

fun isIdle() {
    // DON'T call callback.onTransitionToIdle() here!
}

fun backgroundWorkDone() {
    // Background work finished.
    callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle.

    // Don't do any post-processing work beyond this point. Espresso now
    // considers your app to be idle and moves on to the next test action.
}

Java

public void isIdle() {
    // DON'T call callback.onTransitionToIdle() here!
}

public void backgroundWorkDone() {
    // Background work finished.
    callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle.

    // Don't do any post-processing work beyond this point. Espresso now
    // considers your app to be idle and moves on to the next test action.
}
アイドリング リソースは必要になる前に登録する。

アイドリング リソースに関連する同期のメリットが発揮される そのリソースの Espresso の初回呼び出しの後、 isIdleNow() メソッドを使用します。

この性質の例を以下に示します。

  • アイドリング リソースを @Before アノテーション付きのメソッドに登録すると、 アイドリング リソースは、各テストの最初の行で有効になります。
  • テスト内でアイドリング リソースを登録すると、 は、次の Espresso ベースのアクション中に有効になります。この動作は依然として 次のアクションが、先行するステートメントと同じテストの アイドリング リソースを登録します。
アイドリング リソース使用終了後は登録を解除する。

システム リソースを節約するため、アイドリング リソースの登録を解除してください。 削除することもできますたとえば、アイドル状態のリソースを @Before アノテーションを付けたメソッド内でこのリソースの登録を解除するには、 @After アノテーションが付けられた、対応するメソッドです。

アイドリング リソースの登録と登録解除にはアイドリング レジストリを使用する。

このコンテナをアプリのアイドリング リソースに使用すると、 アイドリング リソースの登録解除を必要に応じて繰り返し行い、一貫した 確認します。

アイドリング リソース内では単純なアプリの状態のみを保持する。

たとえば、アイドリング リソースを実装して登録する場合は、 View オブジェクトへの参照が含まれます。

アイドリング リソースの登録

Espresso には、アプリのアイドリングを配置するコンテナクラスが用意されています 説明します。このクラスは、 IdlingRegistry は、 アプリのオーバーヘッドを最小限に抑える自己完結型のアーティファクトです。クラス では、アプリの メンテナンス性:

  • アイドリング リソースではなく IdlingRegistry への参照を作成する テストで使用します。
  • 使用するアイドリング リソースのコレクションの相違を維持する ビルド バリアントごとに作成されます。
  • UI ではなく、アプリのサービスでアイドリング リソースを定義する それらのサービスを参照するコンポーネントが 含まれます
で確認できます。

アイドリング リソースのアプリへの統合

アイドリング リソースをアプリに追加する方法はいくつかありますが、 アプリのカプセル化を維持しつつ、特定のリソースへの 特定のアイドリング リソースが表す特定のオペレーションを指定できます。

アイドリング リソースをアプリに追加する場合、 アプリ自体でリソース ロジックをアイドル状態にし、登録と テストの登録解除オペレーションを実行します。

テスト専用インターフェースを使用すると、 本番環境のコードに含めることで、アイドル状態のリソースを アプリの APK のサイズとメソッド数を維持します。

その他の方法

アプリの製品版にアイドリング リソースのロジックを含めたくない場合 実行可能なインテグレーション戦略が他にもいくつかあります。

  • ビルド バリアントを作成する(Gradle の プロダクト フレーバーを作成し、アイドリング リソースをアプリのデバッグビルドでのみ使用します。
  • Dagger などの依存関係インジェクション フレームワークを使用して、アプリのアイドリングを注入する リソース依存関係グラフをテストに組み込みます。Dagger 2 を使用している場合、 インジェクション自体は、サブコンポーネントから開始する必要があります。
  • アプリのテストにアイドリング リソースを実装し、その部分を公開する 同期する必要があるアプリの実装を テストです。

    注意: この設計上の決定により、 リソースへの自己完結型の参照を作成すると、 非常にシンプルなアプリ以外のすべてにカプセル化されています。

参考情報

Android テストでの Espresso の使用について詳しくは、 ご覧ください

サンプル