Espresso 閒置資源

閒置資源代表執行結果影響的非同步作業 UI 測試中的後續作業。使用以下容器註冊閒置資源： Espresso，您可以更可靠地驗證這些非同步作業： 測試應用程式

瞭解何時需要閒置資源

Espresso 提供一系列 同步處理功能。這個 此架構的特性，則僅適用於 MessageQueue 上的訊息，例如 View，正在在畫面上繪製內容。

因為 Espresso 不知道任何其他非同步作業，包括 在背景執行緒上執行的應用程式 Espresso 無法提供同步處理 在這些情況下保證為了讓 Espresso 瞭解您應用程式的 您需要將每項作業註冊為閒置資源。

如果您在測試應用程式的結果時未使用閒置資源 您可能會注意到 按照錯誤的方法改善測試可靠性：

• 新增呼叫至 Thread.sleep()。當您 導致測試套件出現人為延遲的情況 但測試在執行時仍可能會失敗 速度較慢的裝置此外，您的應用程式可能會因為 。
• 實作重試包裝函式，迴圈會使用迴圈反覆檢查 您的應用程式仍會執行非同步作業，直到逾時為止。即使 您可以在測試中指定重試次數上限，每次重新執行都會耗用 系統資源，尤其是 CPU
• 使用 CountDownLatch 的執行個體 讓一或多個執行緒等待特定作業數量完成 而在其他執行緒中執行的所有工作都已完成這些物件會要求您指定一個 逾時長度；否則應用程式可能會無限期遭到封鎖。閂鎖 也會增加程式碼的複雜性，使維護更加困難。

Espresso 可讓您從測試和 而是將應用程式的非同步工作註冊為閒置資源。

常見用途

在測試中執行與以下範例類似的作業時 不妨考慮使用閒置資源：

• 從網際網路或本機資料來源載入資料。
• 與資料庫和回呼建立連線。
• 管理服務：使用系統服務或 IntentService。
• 執行複雜的商業邏輯，例如點陣圖轉換。

如果在作業執行這些作業時註冊閒置資源 然後更新測試並驗證的使用者介面。

注意： 部分第三方程式庫使用的執行緒配置需要手動操作 執行緒管理。在這些情況下，請新增執行緒邏輯來達成相同目的 讓您愛不釋手，直接使用閒置資源。

閒置資源實作範例

以下清單說明閒置資源的幾種實作範例 可以整合至應用程式的使用者介面：

CountingIdlingResource

維護計數器。如果計數器為 0， 系統會將資源視為閒置。這項功能就像是 Semaphore。在大多數情況下，這項實作方式為 且充分掌握在測試期間管理應用程式的非同步作業。

UriIdlingResource

類似 CountingIdlingResource, 但計數器必須涵蓋在 系統會將資源視為閒置。這段額外等待期會連續完成 因此執行緒中的應用程式可能會針對網路要求 並立即回覆先前的要求。

IdlingThreadPoolExecutor

ThreadPoolExecutor 的自訂實作方式 追蹤已建立的執行緒內正在執行的工作總數 集區。這個類別使用 CountingIdlingResource 到 有效任務的計數器

IdlingScheduledThreadPoolExecutor

自訂導入 ScheduledThreadPoolExecutor。可提供 IdlingThreadPoolExecutor敬上 但可以追蹤已安排在日後安排的工作 定期執行

，瞭解如何調查及移除這項存取權。

注意： 導入上述 API 後， 只有在 Espresso 首次叫用該資源後，閒置資源才會生效 資源的 isIdleNow() 方法。因此，您必須在需要「先」註冊這些 ID 資源之前 。

建立自己的閒置資源

當您在應用程式測試中使用閒置資源時，可能需要提供 以及自訂資源管理或記錄功能在這些情況下 可能就不足以滿足所有需求出現這種情況時 擴充其中一個閒置資源實作，或自行建立。

如果您實作自己的閒置資源功能，請盡可能使用 特別是第一種做法：

在閒置檢查外叫用閒置狀態的轉換。

應用程式進入閒置狀態後，請呼叫 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 提供容器類別，可用來放置應用程式的閒置功能 再複習一下，機構節點 是所有 Google Cloud Platform 資源的根節點此類別稱為 IdlingRegistry，是 獨立構件，將應用程式的負擔降至最低。課程 也可讓您採取下列步驟，改善應用程式的 可維護性：

• 建立對 IdlingRegistry 的參照，而非閒置資源 進行測試。
• 在用於專案的閒置資源集合中保持差異 每個建構變數都沒問題
• 在應用程式的服務中定義閒置資源，而非透過使用者介面定義 元件。

，瞭解如何調查及移除這項存取權。

注意： IdlingRegistry 類別為 是註冊應用程式閒置資源的唯一支援方法。

將閒置資源整合至應用程式

雖然您可以透過多種方式為應用程式新增閒置資源 特別是保留應用程式的封裝功能，同時 您可以指定特定閒置資源代表的特定作業

建議做法

在應用程式中加入閒置資源時，我們「強烈建議」 在應用程式中放置資源邏輯，且只執行註冊和

雖然您在 只要按照這個方法操作，您就能將 ID 資源包裝在 ，維持應用程式的 APK 大小和方法數量。

其他做法

如果您不想在應用程式的實際工作環境中使用閒置資源邏輯 還有另外幾種可行的整合策略：

• 建立建構變數，例如 Gradle 的 產品 變種版本，並且只在應用程式的偵錯版本中使用閒置資源。
• 使用依附元件插入架構 (例如 Dagger) 插入應用程式的閒置功能 加入測試中的資源依附元件圖如果您使用的是 Dagger 2， 插入內容應來自子元件。

• 在應用程式的測試中實作閒置資源，並公開 因此需要同步處理 測試。

  注意： 雖然這項設計決策似乎 建立用於閒置資源的獨立參照， 除了最單純的應用程式之外，

其他資源

如要進一步瞭解如何在 Android 測試中使用 Espresso，請參閱 資源。

範例

• IdlingResourceSample： 與背景工作同步處理。