Android测试支持库1.0现已发布！

文 / Google Mobile-Ninjas 团队的 Michael Amygdalidis、Stephan Linzner 和 Nick Korostelev

我们非常高兴地宣布，Android 测试支持库 (ATSL) 1.0 版现已发布。

ATSL 1.0 版对现有测试 API 进行了重要更新，不仅添加了许多新功能、还提升了性能和稳定性，同时还修复了若干问题。它可提供齐全的 API，功能与现已弃用的 Android 平台测试 API 相当。此版本还添加了许多我们在 Google I/O 2017 论坛上讨论过的功能，如为 Multiprocess Espresso 和 Android Test Orchestrator 提供原生支持。

我们也非常高兴地宣布，从 1.0 版开始，我们将在 Google 的 Maven 代码库中分发版本，让您能够更轻松地使用 ATSL 进行构建。如需了解有关如何使用此代码库的更多信息，请参阅 Google Maven 代码库入门指南。请注意，今后我们不再将测试基础设施更新与平台更新捆绑在一起。如果您尚未将您的测试升级至 ATSL，这次正是升级的绝佳机会。

最后，我们想要宣布对我们的 Android 测试文档进行的一项重大更新。我们已将旧测试文档从我们的 GitHub 网站迁移至 developers.android.com/testing。所有测试文档现在都显示在同一个位置，让您更容易了解如何在 Android 上编写和执行测试。

下面我们进入本博文的高潮部分，这一部分概要地介绍了我们将在此版本中提供的新 API 和工具。

Espresso 增强功能

Espresso 3.0.0 带来了出色的新功能，并提升了整体性能。其中的一些亮点包括：Multiprocess Espresso、Idling Registry 和新的 Idling Resources。下面，我们更详细地介绍一下这些新功能：

Multiprocess Espresso

从 Android O 开始，此平台将包含对在您的应用默认进程之外进行仪器测试的支持。（在 Android O 之前，您只能在应用默认进程中测试应用组件。）Multiprocess Espresso 实现了这一支持。它允许您无缝测试跨进程界限的应用界面交互，同时仍可保证 Espresso 同步。

好消息是，Espresso 可执行上述所有工作；您不必针对多进程对界面设置进行任何更改。您可以继续像为单进程应用编写测试一样为多进程编写 Espresso 测试，Espresso 将自动处理进程间通信 (IPC) 和进程间同步。

下图展示了 Espresso 的多个实例如何相互通信：

如需了解有关 Multiprocess Espresso 及其用法的更多信息，请查看我们的文档：

https://developer.android.google.cn/training/testing/espresso/multiprocess.html

Multiprocess 示例：

https://github.com/googlesamples/android-testing/tree/master/ui/espresso/MultiProcessSample

Idling Registry

有些应用使用 Gradle 中的构建风味或依赖注入框架（如 Dagger）来生成注册空闲资源的测试构建配置。其他应用只是通过其操作组件公开空闲资源。所有这些方法都存在一个问题，即它们会增加开发工作流程的复杂性，其中有些方法甚至会破坏封装。借助最新版本的 Espresso，通过引入新的 IdlingRegistry API，让您可以更轻松地在应用代码中注册空闲资源。IdlingRegistry 是一个轻量型注册表，它不会引入完整的 Espresso 库，因此，您可以更轻松地从您的应用代码注册资源。将此 API 与 Multiprocess Espresso 结合使用时，您可以在应用代码中注册来自任何进程的空闲资源。

Espresso 类的注册现已弃用。
Idling Resources
编写自定义空闲资源非常耗时，因此，Espresso 3.0.0 现在附带了更多可以直接使用的空闲资源，以同步您的线程。新资源包括：IdlingThreadPoolExecutor 和 IdlingScheduledThreadPoolExecutor。我们还将提供更多资源！

要利用新的空闲资源，请将以下新的依赖项添加到 build.gradle 文件：

  androidTestCompile "com.android.support.test.espresso.idling:idling-concurrent:3.0.0"

此外，之前在 Espresso contrib 中弃用的 CountingIdlingResource 已在此版本中移除。因此，您需要更新您的测试以使用新的 CountingIdlingResource 软件包，其位于 Espresso 空闲资源中。如需完整的迁移详细信息，请参阅我们的版本说明：

https://developer.android.google.cn/topic/libraries/testing-support-library/release-notes.html

ProviderTestRule

现在，测试 ContentProvider 对象时，您可以使用 ProviderTestRule 替代 ProviderTestCase2。ProviderTestRule 让您可以更轻松地使用 AndroidJUnit4 当前可用的其他测试规则。

ProviderTestRule 包括用于初始化的 API，以及针对正在测试的 ContentProvider 运行的命令。如果您的 ContentProvider 基于 SQLite 数据库，您可以使用用于设置数据库文件的 ProviderTestRule 命令和初始化命令。

如需了解更多信息，请查阅 ProviderTestRule 文档：

https://developer.android.google.cn/reference/android/support/test/rule/provider/ProviderTestRule.html

授予权限规则

Android M（API 级别 23）允许应用在运行时请求权限。不过，请求运行时权限的对话框将使测试进入无法继续的状态，从而导致测试失败。通过使用 GrantPermissionRule，您可以跳过所有弹出对话框，并模拟用户为您的应用授予运行时权限。

Android Test Orchestrator

AndroidJUnitRunner 通常在同一个仪器进程中运行所有测试，这会导致许多问题。例如，这些测试会共享它们在内存中的状态，如果一个测试崩溃，它将阻止测试套件的其余测试运行。

尽管可以通过发起序列 adb 命令隔离测试，但此进程会增加主机端处理负载。通过改用全新的 Android Test Orchestrator，您可以在设备上实现完全的测试隔离，如下图所示：

请注意，如果您的测试 需要 传递共享状态，则协调器会导致它们失败。此行为是设计使然。截至本博文发布时，Android Test Orchestrator 已进入 Beta 测试阶段，可通过命令行使用。我们计划不久推出 Firebase Test Lab 和 Android Studio 集成。

如需了解详细信息，请参阅 Android Testing Orchestrator 开发者指南：

https://developer.android.google.cn/training/testing/junit-runner.html#using-android-test-orchestrator

AndroidJUnitRunner

AndroidJUnitRunner 现在包含许多附加功能：

• 您可以使用 JUnitParams。

• 您可以使用运行器参数来配置类加载器和自定义 JUnit 测试过滤器。

有时，作为测试工作流程的一部分，您需要对您实时创建和配置的操作组件进行测试。现在，您可以使用一个 InterceptingActivityFactory 配置 MonitoringInstrumentation（并扩展到 AndroidJUnitRunner）。您可以使用一个特定于测试的配置创建要测试的操作组件，无需依赖编译时注入。

上面的概述仅重点介绍了我们对 ATSL 进行的一些最重要变更。此外，还有更多值得探索的变更。如需完整的版本详细信息，请参阅我们的版本说明：