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 文件:
此外,之前在 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 进行的一些最重要变更。此外,还有更多值得探索的变更。如需完整的版本详细信息,请参阅我们的版本说明:
https://developer.android.com/topic/libraries/testing-support-library/release-notes.html
最后,我们想感谢为此版本贡献功能的所有开发者。我们还要感谢来自 American Express、Slack 的移动工程团队的 Android 测试专家以及 GDE Chiu-Ki Chan,感谢他们与我们大力合作和针对 Android 测试支持库预发行版提供宝贵的反馈意见。
ATSL 团队祝您测试愉快!
查看全文及文中链接,请点击文末“阅读原文”。
推荐阅读:
Google现已推出Android版Motion Stills