在本文中，您将了解如何在 Compose 中使用 waitUntil 测试 API 来等待满足特定条件。在某些情况下，这是一种很好的替代方案，可以替代 Idling Resources。

[2023 年更新] 简而言之：使用新的 waitUntil 系列 API 在 Compose 测试 (v1.4.0+) 中进行同步。

什么是同步？

对测试进行分类的一种方法是按其范围进行分类。小型测试（或单元测试）侧重于应用的小部分，而大型测试（或端到端测试）则涵盖应用的大部分。您可以在新更新的测试文档中了解这方面的内容以及其他类型的测试。

按 Enter 键或点击以全尺寸查看图片

同步 是一种机制，可让测试知道何时运行下一个操作。您选择验证的代码块越大，与测试同步就越困难。在单元测试中，您可以轻松完全控制要验证的代码的执行。但是，随着范围扩大到包含更多类、模块和层，测试框架很难知道应用是否正在执行操作。

按 Enter 键或点击以全尺寸查看图片

androidx.test 以及 Compose 测试（作为其扩展）在后台使用了一些技巧，因此您不必过于担心这一点。例如，如果主线程繁忙，测试会暂停，直到可以执行下一行代码为止。

不过，它们不可能知道所有情况。例如，如果您在后台线程中加载数据，测试框架可能会过早执行下一个操作，导致测试失败。最糟糕的情况是，这种情况只在很小一部分时间内发生，导致测试不稳定。

选项 1：Idling Resources

Idling Resources 是一项 Espresso 功能，可让开发者决定应用何时处于繁忙状态。您可以通过以下两种方式使用它们：

1. 将它们安装在执行测试无法看到的工作的框架或库中。

RxIdler 就是一个很好的例子，它封装了 RxJava 调度器。这是注册 Idling Resources 的首选方式，因为它可让您将测试设置与测试代码清晰分离。

**2. 修改受测代码，以明确公开有关应用是否处于繁忙状态的信息。

例如，您可以修改存储库（或一个 测试替身），以指示在从数据源加载数据时处于繁忙状态：

这并非理想的做法，因为您会污染生产代码或创建复杂的测试替身，并且在某些情况下很难安装它们。例如，如何在 Kotlin Flow 中使用 Idling Resources？哪个更新是最终更新？

相反，我们可以等待事物。

选项 2：等待事物…错误的方式

加载数据通常很快，尤其是在使用假数据时，因此，如果只需让测试休眠几秒钟，为什么还要浪费时间使用 Idling Resources？

此测试要么运行速度低于所需速度，要么会失败 。当您有数百或数千个界面测试时，您希望测试尽可能快。

此外，有时模拟器或设备的行为不当且出现卡顿，导致该操作花费的时间比 2000 毫秒稍长，从而导致 build 失败。当您有数百个测试时，这会成为一个巨大的问题。

选项 3：以正确的方式等待事物！

如果您不想修改受测代码以公开其繁忙时间，另一种选择是等待满足特定条件，而不是等待任意时长。

在 Compose 中，您可以利用 waitUntil 函数，该函数会接受另一个生成布尔值的函数。

2023 年 3 月 22 日更新：从 Compose 1.4.0 开始，我们添加了一组新的 waitUntil 系列 API：

[1.4.0 之前的版本：使用以下帮助程序：waitUntilExists、waitUntilNodeCount]

…并按如下方式使用它们：

仅当需要将测试与界面同步时，才使用这些 API。对每个测试语句进行同步轮询会不必要地污染测试代码，使其更难维护。

那么，您应该何时使用它？一个很好的用例是从可观测对象（使用 LiveData、Kotlin Flow 或 RxJava）加载数据。当您的界面需要接收多次更新，然后您才认为其处于空闲状态时，您可能需要使用 waitUntil 简化同步。

例如，当您从视图收集 Flow 时：

并向其发出多个项：

如果 repository 需要不确定的时间才能返回第一个结果，测试框架会认为“Loading”是空闲状态（在 collectAsState 中分配的初始值），并继续执行下一个语句。

因此，如果您确保界面未显示加载指示器，则可以使测试更加可靠：

快乐地…等待…测试！

代码段许可：

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