为了使大家确信“应做单元测试，就一定能做单元测试”，谷歌测试工程师 Mona El Mahdy 专门写了一篇博客，提出了几种执行安卓应用用户界面单元测试的方法。Mahdy 推荐使用 Robolectric 和 Android Studio Gradle 插件做常规的单元测试，用 Espresso 或 UI Automator 创建和运行单元测试。
端到端的测试。Mahdy 提出的第一种 UI 测试方法是 E2E。这样的测试应该可以启动安卓应用及其所有与之相关的后端系统，使之可以在真实的场景中完成 UI 测试。重复执行这些的测试是很困难的，因为“存在很多的影响因素，比如网络带宽、实际服务器的认证、系统规模等”，所以就很难做到“E2E 测试的调试排查和稳定化处理”。为简化这些点，Mahdy 也提出了一些其他的测试策略。
用隔离的服务器测试。隔离的服务器是指与外界隔离的服务器，是在本地运行的一台单独的服务器，不连接网络。在运行的时间通过依赖注入（可能需要绑定到这台服务器的静态文件）的方式提供与其他服务器的连接，如果需要的话，还可以在本地文件或内存存储中伪造一些响应数据。另一个选择是，为隔离的服务器提供一系列记录好的响应，以模拟真实终端服务器的返回值。
针对测试目的，隔离的服务器作为被测系统在同一台机器上本地运行，其上运行安卓模拟器。虽然这种方式提高了测试的执行速度，有时也会消除一些网络连接的碎片，但是它需要单独的集成测试以确保客户端应用与后端是同步的。出于这个目的，Google+ 团队用了一组“黄金的”需求/ 响应文件，大家都知道它们包含了客户端应用到终端服务器的正确的传输序列。用黄金的需求文件根据这台服务器的所有响应生成一个文件，然后再用这个文件与黄金的响应文件进行比较。
Mahdy 提出，使用隔离的服务器比 E2E 测试可以更好地完成测试，但是调试却仍旧是个难题，而且这台隔离的服务器可能会导致一些通讯碎片。所以，她提出了另一个改进方案。
使用依赖注入（DI）。移动应用可以设计成支持依赖注入的，在测试期间有些模块可以用仿造模块代替。应用将和仿造的网络模块进行通讯，这个网络模块为所有请求提供应答，以取代刚才所讲的使用网络模块的隔离的服务器。这会使 UI 测试更快更可靠。在 DI 这一方面，Mahdy 建议使用 Dagger 。
多重类库。如果安卓应用比较大，Mahdy 建议把它分割成更多小的组件，每个和它自己的模块和视图把包到一个单独的类库中。然后，你们就可以使用单独的 DI、模拟模块和测试进行每个组件的开发和测试了。为确保整个应用的运转，需要集成的测试。这一方式更是进一步提升了测试的速度。
最后，Mahdy 总结道：“组件化的 UI 测试要比 E2E 测试快得多，并具备 99% 的稳定性。快速而稳定的测试从根本上提升了开发人员的生产效率。”
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论