随着 Agile 的普及以及开发人员对测试重要性的认识逐步加深，大连系统开发Android中的单元测试已经成了越来越多软件项目开发中不可缺少的一部分。无论项目是不是采用TDD的形式来进行开发，单元测试都能够为项目的修改和重构提供一定的保障。

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

      大连系统开发Android中的单元测试环境中集成了一个测试框架（Instrumented Test），用于支持其单元测试和验收测试。Robotium同样提供一个类似于Selenium的测试框架，使得开发人员可以对应用的功能进行验证。

      致远服软认为：http://www.soft8.com.cn/这两种方式提供的测试环境都类似于集成测试，它们的测试用例都需要在模拟器上运行，通过对模拟器的操作或者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相关的代码进行测试，以保证测试率。

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