本頁面由 Cloud Translation API 翻譯而成。

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敬上但可以追蹤已安排在日後安排的工作定期執行

建立自己的閒置資源

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

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

在閒置檢查外叫用閒置狀態的轉換。: 應用程式進入閒置狀態後，請呼叫 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 的參照，而非閒置資源進行測試。
在用於專案的閒置資源集合中保持差異每個建構變數都沒問題
在應用程式的服務中定義閒置資源，而非透過使用者介面定義元件。

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

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

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

建議做法

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

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

其他做法

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

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

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

其他資源

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

範例

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