Robolectric介绍

随着市场竞争加剧，手工回归测试已不能支持产品的快速发布。以及开发人员对测试重要性的认识逐步加深，单元测试已经成了软件项目开发中不可缺少的一部分。无论项目是不是采用TDD的形式来进行开发，单元测试都能够为项目的修改和重构提供很好的保障。

Android作为主要的移动平台之一，吸引了无数的开发人员。但面对Android平台和环境的种种限制，很多开发人员往往有心无力，很难为其项目添加全面有效的单元测试。

Android平台的开发环境中集成了一个测试框架(Instrumented Test)，用于支持其单元测试和验收测试。Robotium同样提供一个类似于Selenium的测试框架，使得开发人员可以对应用的功能进行验证。这两种方式提供的测试环境都类似于集成测试，它们的测试用例都需要运行在模拟器上，通过对模拟器的操作或者mock，来触发函数调用，进而对其结果进行验证。这种方法通常粒度较大，测试的编写和维护较为困难，而最为重要的是，由于测试需要运行于模拟器或测试机器上，我们在运行前需要将测试和应用打包，进行部署安装，并最终运行在模拟器或测试机器的Delvik虚拟机上，其运行速度较普通的单元测试要慢许多，如果使用TDD来进行开发，根本无法达到快速开发的要求。

之所以这些框架的测试用例都需要在模拟器中运行，是因为我们平时在开发时所使用的Andorid.jar是被精简过的，只是用于日常开发的，它只是一个placeholder，使得我们在开发时能够不出编译错误，它完全是一个stub包，其中所有的类都只是Android平台接口的一个stub，如果在代码中运行这个Android.jar，它们所有的方法都只会抛出一个java.lang.RuntimeException(“Stub!”)异常。所以，一旦测试代码需要真正调用Android平台相关的类或接口，它们就必须运行于真正实现了Android的环境，如模拟器或者是测试机器。

我们的另外一个选择是只对POJO进行单元测试，如果遇到Android相关的代码，就使用Mock框架对其进行模拟。这种方式一定程度上可以解决我们的问题，但这意味着我们需要大量的在测试环境中使用mock和stub。另外，虽然Android中界面的布局通常使用XML来实现，但项目的代码中还是会存在各种对界面的操作和更新，UI和逻辑的耦合使测试更加不易。

而且即使这样，由于Android平台的复杂性（static方法，final方法和类，Context和Resources的管理），我们也很难对Android相关的代码进行测试，以保证测试率。

那么如何能够在不增加开发成本的情况下，有一个稳定快速的单元测试环境呢？

Robolectric在其所提供的测试框架中，完全模拟了Android SDK的jar文件（不会再有恼人的stub异常），它使得我们的测试可以运行于JVM之上（速度得到大幅度的提升），因此我们可以用它对Android应用进行测试驱动开发。Roblectric同时实现了Android中对XML的解析，模拟了View，Layout，以及资源的加载，它使得Android的环境对于开发人员来说更像是一个黑盒，从而使开发人员不用大量使用mock，就可以方便的对资源状态和Android相关的代码进行测试。

Robolectric是如何做到这点的呢？

Robolectric使用了javassist在运行时动态修改Android.jar中类的byte code，Robolectric会在JVM加载Android.jar包的时候，重写其中类的方法。Roblectroic会让这些方法有返回值（null或是0） 而不是抛出异常 ，或者将这些方法调用转向Shadow Objects来模拟Android SDK的实现。

Shadow Objects是Robolectric在运行时插入到Android.jar包相应的类中的，它们会实际处理方法的调用，并记录相应的状态，以备在assert的时候进行查询。如图所示。Robolectric提供了大量的Shadow Objects，覆盖了测试开发过程中绝大多数逻辑功能的需要。