Compose 測試中閒置資源的替代方案：waitUntil API (更新版)

本文將說明如何在 Compose 中使用 waitUntil 測試 API，等待特定條件達成。在某些情況下，這是使用閒置資源的絕佳替代方案。

[2023 年更新] 摘要：在 Compose 測試 (1.4.0 以上版本) 中，請使用新的 waitUntil API 進行同步處理。

什麼是同步？

測試可依範圍分類。小型測試或單元測試著重於應用程式的小部分，大型測試或端對端測試則涵蓋應用程式的大部分。如要瞭解這類和其他類型的測試，請參閱新版測試文件。

按下 Enter 鍵或按一下即可查看原尺寸的圖片

同步機制可讓測試瞭解何時執行下一個作業。您選擇驗證的程式碼區塊越大，就越難與測試同步。在單元測試中，您可以輕鬆全面掌控程式碼的執行作業，以便進行驗證。不過，隨著範圍擴大，納入更多類別、模組和層，測試架構會難以判斷應用程式是否正在執行作業。

按下 Enter 鍵或按一下即可查看原尺寸的圖片

androidx.test 和 Compose 測試 (延伸功能) 在幕後使用一些技巧，因此您不必太擔心這類問題。舉例來說，如果主執行緒忙碌中，測試會暫停，直到可以執行下一行程式碼為止。

但他們無法得知所有資訊。舉例來說，如果您在背景執行緒中載入資料，測試架構可能會過早執行下一個作業，導致測試失敗。最糟糕的情況是，這種情況只在少數時間發生，導致測試不穩定。

選項 1：閒置資源

閒置資源是 Espresso 功能，可讓開發人員決定應用程式何時處於忙碌狀態。使用方式有兩種：

1. 將這些項目安裝在測試無法查看的架構或程式庫中。

RxIdler 就是一個很好的例子，這個類別會包裝 RxJava 排程器。建議您採用這種方式註冊閒置資源，因為這樣可以將測試設定與測試程式碼清楚分開。

2. 修改受測程式碼，明確公開應用程式是否忙碌的相關資訊。

舉例來說，您可以修改存放區 (或測試替身)，指出從資料來源載入資料時忙碌：

這並非理想做法，因為您會汙染正式版程式碼或建立複雜的測試替身，而且在某些情況下，這些替身難以安裝。舉例來說，您會在 Kotlin Flow 中如何使用閒置資源？哪一項更新是最終更新？

相反地，我們可以等待。

選項 2：等待事物…但方式錯誤

載入資料通常很快，尤其是使用虛擬資料時，因此何必浪費時間讓資源閒置，只要讓測試休眠幾秒鐘即可。

這項測試執行速度會比必要速度慢，或會失敗。如果您有數百或數千項 UI 測試，一定希望測試能盡快完成。

此外，有時模擬器或裝置會發生錯誤和卡頓，導致作業時間超過 2000 毫秒，進而中斷建構作業。如果您有數百項測試，這就會成為大問題。

選項 3：以正確方式等待！

如果不想修改測試中的程式碼，以顯示程式碼忙碌的時間，可以等待特定條件達成，而不是等待任意時間。

在 Compose 中，您可以運用 waitUntil 函式，該函式會採用產生布林值的另一個函式。

2023 年 3 月 22 日更新：從 Compose 1.4.0 開始，我們新增了一組 waitUntil API：

[1.4.0 之前的版本：請使用這些輔助程式：waitUntilExists、waitUntilNodeCount]

…並依下列方式使用：

只有在需要將測試與 UI 同步處理時，才使用這些 API。在每個測試陳述式上同步處理會不必要地汙染測試程式碼，導致維護更加困難。

那麼何時該使用呢？這項功能很適合從可觀察物件 (使用 LiveData、Kotlin Flow 或 RxJava) 載入資料。如果 UI 需要接收多項更新，才會被視為閒置，您或許可以透過 waitUntil 簡化同步作業。

舉例來說，從檢視區塊收集 Flow 時：

並向其中發出多個項目：

如果 repository 需要不確定的時間才能傳回第一個結果，測試框架會將「Loading」視為閒置狀態 (在 collectAsState 中指派的初始值)，並繼續執行下一個陳述式。

因此，如果確保 UI 未顯示載入指標，測試的可靠性就會大幅提升：

預祝測試愉快！

程式碼片段授權：

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0