在本文中，您将学习如何在 Compose 中使用 waitUntil 测试 API 来等待特定条件得到满足。在某些情况下，这是使用空闲资源的理想替代方案。

[2023 年更新] 总结：在 Compose 测试中使用新的 waitUntil API（v1.4.0 及更高版本）进行同步。

什么是同步？

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

按 Enter 键或点击即可查看完整尺寸的图片

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

按 Enter 键或点击即可查看完整尺寸的图片

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

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

选项 1：Idling Resources

空闲资源是 Espresso 的一项功能，可让开发者决定应用何时处于繁忙状态。您可以通过以下两种方式使用这些数据：

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

RxIdler 就是一个很好的例子，它封装了 RxJava 调度程序。这是注册空闲资源的首选方式，因为它可以让您将测试设置与测试代码清晰地分开。

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

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

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

相反，我们可以等待。

选项 2：错误的等待方式

加载数据通常很快，尤其是在使用虚假数据时，因此，当您只需让测试休眠几秒钟时，为何要浪费时间让资源处于空闲状态？

此测试将运行速度过慢或失败。当您有数百或数千个界面测试时，您希望测试尽可能快。

此外，有时模拟器或设备会运行异常并出现卡顿，导致该操作耗时略长于 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 需要不确定的时间才能返回第一个结果，测试框架会认为“加载”是空闲状态（在 collectAsState 中分配的初始值），并继续执行下一条语句。

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

祝您…稍等…测试顺利！

代码段许可：

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