官方文档链接：https://developer.android.google.cn/training/testing/fundamentals.html
1.前言
在之前的文章中大概地描述了进行安卓测试的准备事项，让大家有个总体的感受。由于当时急着在项目中粗浅地体验一下，所以了解点皮毛后就没有继续深入了。直到前不久看了Google I/O大会的资料，才发现测试驱动开发（TDD）是一件很必要的事情，决定好好研究一下。那从何开始呢？除了大会视频外，官方网站的文档是我最喜欢的学习途径。
2.测试的重要性
测试应用程序是开发过程的一个组成部分。通过持续地对应用程序进行测试，可以在公开发布之前，验证它的正确性、功能性和可用性。除此之外，还有以下优点：
- 快速反馈问题。
- 在开发周期的早期发现问题。
- 更安全地重构代码，不用担心优化代码时重新引入问题。
- 稳定开发速度，有助于减少技术债。
用户在按下提交按钮到向自己设备下载数据的过程中，与应用程序的各个层级交互。因此，在迭代开发应用程序时，应该测试各种用例和交互。
3.使用迭代开发工作流
随着应用程序扩展，可能会发现需要从服务端获取数据、与设备传感器交互、访问本地存储或渲染复杂的用户界面，一个全面的测试策略必不可少。
迭代开发功能，从写一个新的测试或给已存在的单元测试添加用例和断言开始。由于还没有实现功能，第一次测试会失败。在设计新功能时，考虑划分出的单元的职责很重要。每个单元，都需编写相应的单元测试，考虑与它所有可能的交互，包括正常交互、无效输入和资源无效的情况。
上图所示的完整工作流包含嵌套的迭代周期，一个长而慢的UI测试周期集成代码单元的测试，使用更短、更快的周期测试这些单元，整个周期持续到应用程序满足每个用例。
4.了解测试层级
下图的测试层级，展示了应用程序应该包括三类测试：小型、中型和大型：
- 小型测试指单元测试，可以独立于生产环境运行。通常模仿每个主要组件，且在开发机器上快速运行。
- 中型测试指集成测试，处于小型和大型测试之间。集成几个组件，并在模拟器或真实设备上运行。
- 大型测试指集成和UI测试，运行完整的UI工作流。确保关键的用户交互任务，按照预期在模拟器或真实设备上运行。
虽然小型测试快速和直接，允许迅速发现问题，但由于低保真和独立性，让人很难相信通过测试的应用程序能正常工作，而编写大型测试正好能弥补。因为每个测试类型有不同的特点，应该包含所有层级的测试。尽管每个类型的测试所占比例会根据应用程序的使用情况而不同，通常推荐以下分配方式：小型占70%，中型占20%，大型占10%。
5.编写小型测试
当添加和改变应用程序的功能时，确保它们能通过针对地创建和运行的单元测试。虽然可以在设备或模拟器上评估单元，但在开发环境测试单元通常更加快捷和简单，当需要与安卓系统交互时添加桩或模拟方法。
5.1.Robolectric
如果应用程序的测试环境要求在单元测试中与安卓框架进行更多的交互，可以使用Robolectric。这个工具使用对测试友好、基于Java的逻辑桩（由社区维护）来模拟安卓框架。它测试的保真度接近于在安卓设备上运行测试，同时仍比设备测试执行更快，还支持安卓平台以下几个方面：
- Android 4.1（API 16）及以上版本
- Android Gradle插件2.4及以上版本
- 组件的生命周期
- 事件循环
- 所有资源
Robolectric拥有自己的一套测试API，并引入一些新的概念。 有关将Robolectric的API与应用程序的测试集成的更多信息，请参阅该工具的用户指南。
5.2.模拟对象
可以通过针对修改后的android.jar运行单元测试，来管理与应用程序交互的安卓框架的元素。这个JAR文件不包含任何代码，所以应用程序调用安卓框架默认会抛出异常。为了测试与安卓系统交互的代码元素，使用像Mockito这样的框架来配置模拟对象。如果代码中包含对资源的引用或与安卓框架复杂的交互，应该使用不同形式的单元测试，例如Robolectric。
5.3.设备的单元测试
也可以在物理机或模拟器上运行设备的单元测试，不需要任何模拟或站桩的框架。因为这种形式的测试执行时间明显慢于本地单元测试，所以仅当必须在真实设备硬件上评估应用程序行为时，才使用这种方法。
6.编写中型测试
在开发环境下测试完应用程序的每个单元后，应该在模拟器或设备上验证组件行为的正确性，中型测试可以完成这部分的开发过程。当一些应用程序组件依赖于物理硬件时，这样测试的创建和运行很重要。
中型测试评估应用程序如何协调多个单元，并不测试整个应用程序，例如服务测试、集成测试和模拟外部行为的单独UI测试。通常情况下，最好在模拟器或类似Firebase测试平台等基于云的服务上测试应用程序，而不是在物理设备上，这样可以方便快速地测试多种屏幕尺寸和硬件配置。
7.编写大型测试
尽管单独测试应用程序每个层级和功能很重要，但测试完整工作流程和使用涉及UI、业务逻辑和数据层的测试用例同样重要。如果应用程序足够小，可能只需要一套大型测试来评估整体功能。否则，应该通过团队组成、垂直功能或用户目标划分大型测试。
除了编写大型、基于工作流的测试，也应该编写检查工作流中每个UI组件功能的中型测试。这样，即使相应的大型测试在开始的几个步骤中一直失败，仍然可以通过用户的每个关键操作识别潜在问题。
8.AndroidJUnitRunner
AndroidJUnitRunner类定义一个基于设备的JUnit测试运行器，可以在安卓设备上运行JUnit 3或JUnit 4样式的测试类。测试运行器有助于加载测试包和被测试的应用程序到设备或模拟器上，运行测试和报告结果。此类还支持安卓测试支持库（ATSL）中的以下工具和框架：
8.1.JUnit4 规则
ATSL包含测试中涉及管理应用程序关键组件生命周期的代码，如Activity和Service。要了解如何定义这些规则，请参阅JUnit4规则指南。
8.2.Espresso
Espresso同步异步任务，同时自动执行以下应用程序内交互：
- 在View对象上执行操作。
- 在Android 8.0（API 26）及以上版本支持跨应用程序进程完成工作流程。
- 评估有直接需求的用户能够如何使用应用程序。
- 定位、激活RecyclerView和AdapterView对象中的items。
- 验证传出意图的状态。
- 验证WebView对象中DOM的结构。
- 跟踪应用程序中长时间运行的后台操作。
要详细了解这些交互及在应用程序测试中如何使用它们，请参阅Espresso指南。
8.3.UI Automator
注意：建议仅当应用程序必须与系统交互以完成关键的用例时，使用UI Automator测试。因为它与系统软件和UI交互，每次系统更新后（包括安卓平台版本升级和Google Play服务新版本），需要重新运行和修复UI Automator测试。
作为使用UI Automator替代方案，建议增加独立测试或将大型测试拆分为一系列小型和中型测试。尤其是，每次只关注应用程序内一段通信的测试，例如向其它应用程序发送信息和响应意图结果。Espresso-Intents工具有助于编写这些较小的测试。
UI Automator框架在应用程序的支持下，与系统软件执行交互，例如检查当前显示UI的层次结构、截屏和分析设备的当前状态。更多细节关于UI Automator如何才能观察被测试的应用程序，请参阅UI Automator指南。
8.4.安卓测试控制器
安卓测试控制器让每个UI测试分别在它们自己的Instrumentation沙盒中运行，通过减少测试和每次独立测试导致应用程序崩溃之间共享的状态，增加测试的可靠性。更多信息关于它提供的测试应用程序的好处，请参阅安卓测试控制器指南。
9.总结
若大家没用过测试支持库，建议认真看看官方文档（上面有提供链接，不用担心语言问题，已经支持中文了），根据提示安装相应的包，并在项目中配置好Gradle依赖。后面的几篇文章，将细细分析每种测试的使用方式。