このページは Cloud Translation API によって翻訳されました。

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 ではなく、アプリのサービスでアイドリングリソースを定義するそれらのサービスを参照するコンポーネントが含まれます

で確認できます。

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

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

その他の方法

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

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

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

参考情報

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

サンプル

IdlingResourceSample: バックグラウンドジョブとの同期。

Espresso アイドリング リソース

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