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

我们非常高兴地宣布，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 及其用法的更多信息，请查看我们的 文档 和  Multiprocess 示例 。
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 空闲资源中。如需完整的迁移详细信息，请参阅我们的 版本说明 。

ProviderTestRule

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

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

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

授予权限规则

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 开发者指南 。

AndroidJUnitRunner

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

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

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

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

最后，我们想感谢为此版本贡献功能的所有开发者。我们还要感谢来自 American Express、Slack 的移动工程团队的 Android 测试专家以及 GDE Chiu-Ki Chan，感谢他们与我们大力合作和针对 Android 测试支持库预发行版提供宝贵的反馈意见。

ATSL 团队祝您测试愉快！

原文链接

http://developers.googleblog.cn/2017/08/android-10.html