前言
　　让我一起来看看 Iván Carballo和他的团队是如何使用Espresso， Mockito 和Dagger 2 编写250个UI测试，并且只花了三分钟运行成功的。
　　在这篇文章中，我们会探索如何使用Mockito（译者注：Mockito是java编写的一个单元测试框架），Dagger 2 去创建快速可靠的Android UI测试。如果你正在开始编写Android中的UI 测试或者希望改善已有测试性能的开发者，那么这篇文章值得一读。
　　我第一次在安卓应用中使用UI自动化测试是在几年前使用Robotium（译者注：Robotium是android中的一个自动化测试框架）。我认为测试环境越逼真越好。在终测试中应当表现得如同超人一般能够迅速的点击任意一个位置而且并不会报错，对吧？我认为mocking测试很糟糕。为什么我们需要在测试的时候改变应用的行为?那不是欺骗吗？几个月后我们有了大概100个测试用例要花费40分钟去运行起来。它们是如此的不稳定，即使应用的功能上并没有任何错误，通常有一大半的几率会运行失败。我们花了大量的时间去编写它们，但是这些测试用例却没有帮我们找到任何问题。
　　但正如John Dewey所说，失败是具有启发意义的。
　　失败是有启发意义的。智者总能从失败和成功中学到同样多的东西。
　　我们确实学到。我们认识到在测试中依赖于真实的API 接口是一个糟糕的做法。因为你失去了对返回的数据结果的控制，你也不能对你的测试做预先处理。也是说网络错误和外部API接口错误都会导致你的测试出错。如果你的wifi出错了，你肯定不希望你的测试也会跟着出错。你当然希望这时UI测试能够成功运行。如果你还依赖外部的API接口那么你完全是在做集成测试（integration tests），也得不到我们期望的结果。
　　Mock测试正式解决之道
　　（Mocking is the solution）
　　Mock 测试也是通过一个模拟（mock）的对象去替换一个真实的对象以便于测试。它主要应用于编写单元测试，但在UI测试中也会非常有用。你可以参照不同的方法去模拟java对象但使用Mockito 确实是一个简单有效的解决方案。在下面的例子中你可以看到一个模拟的UserApi 类并且stub（译者注：stub，也即“桩”，主要出现在集成测试的过程中，从上往下的集成时，作为下方程序的替代。可以理解为对方法进行预先的处理，达到修改的效果。下文中不做翻译）了其中的一个方法，因此它总会返回一个用户名username的静态数组。
　　class UsersApi {
　　String[] getUserNames() { }
　　}
　　// Create the mock version of a UsersApi class
　　UsersApi mockApi = Mockito.mock(UsersApi.class);
　　// Stub the getUserNames() method
　　when(mockApi.getUserNames())
　　.thenReturn(new String[]{"User1"， "User2"， "User3"});
　　// The call below will always return an array containing the
　　// three users named above
　　mockApi.getUserNames();
　　一旦你创建了一个mock对象你需要确保应用测试的时候使用的是这个模拟的对象，并且在运行的时候使用的是真实对象。这也是一个难点所在，如果你的代码构建得并不是易于测试（test-friendly）的，替换真实对象的过程会变得异常艰难甚至是说不可能完成。还要注意的是，你想要模拟的代码必须独立到一个单独的类里面。比如说，如果你直接从你的activity中使用HttpURLConnection调用REST API 进行数据访问（我希望你不要这么做）， 这个操作过程模拟起来也会非常困难。
　　在测试之前考虑一下系统架构，糟糕的系统架构往往会导致测试用例和mock测试难于编写，mock测试也会变得不稳定。
　　一个易于测试的架构
　　A test friendly architecture
　　构建一个易于测试的架构有许多种方式。在这里我将使用 ribot 中使用的架构 （译者注：也是在开篇提到的Android应用架构）作为范例，你也可以应用这样的架构方式到任何架构中。我们的架构是基于MVP模式，我们决定在UI测试中去模拟（mock）整个Model层，因此我们可以对数据由更多的操作性，也能够写出更有价值和可靠的测试。


MVP架构

　　DataManager是Model层中暴露给Presenter层的数据的类，因此为了测试Model层我们只需要替换为一个模拟
　　的DataManger即可。
　　使用Dagger注入模拟的DataManager
　　Using Dagger to inject a mock DataManager
　　一旦我们明确了需要模拟什么对象，那么接下来该考虑在测试中如何替换真实的对象。我们通过Dagger2 解决这个问题（一个Android中的依赖注入框架），如果你还没有接触过Dagger ，在继续阅读下去之前我建议你阅读使用Dagger2 进行依赖注入【英】 。我们的应用至少包含一个Dagger 的Module和Component。通常被叫做ApplicationComponent 和ApplicationModule。你可以在下面看到一个简化版的只提供了DataManger实例的类。当然你也可以采用第二种方法，在DataManager的构造函数上使用@inject注解。这里我直接提供一个方法便于理解。（译者注：这里将两个类ApplicationComponent 和ApplicationModule写在一起，便于直观理解）
　　@Module
　　public class ApplicationModule {
　　@Provides
　　@Singleton
　　public DataManager provideDataManager() {
　　return mDataManager;
　　}
　　}
　　@Singleton
　　@Component(modules = ApplicationModule.class)
　　public interface ApplicationComponent {
　　DataManager dataManager();
　　}
　　应用的ApplicationComponent 在Application类中初始化:
　　public class MyApplication extends Application {
　　ApplicationComponent mApplicationComponent;
　　public ApplicationComponent getComponent() {
　　if (mApplicationComponent == null) {
　　mApplicationComponent = DaggerApplicationComponent.builder()
　　.applicationModule(new ApplicationModule(this))
　　.build();
　　}
　　return mApplicationComponent;
　　}
　　// Needed to replace the component with a test specific one
　　public void setComponent(ApplicationComponent applicationComponent) {
　　mApplicationComponent = applicationComponent;
　　}
　　}
　　如果你使用过Dagger2，你可能有同样的配置步骤，现在的做法是创建一个test的时候需要用到的Module和Component
　　@Module
　　public class TestApplicationModule {
　　// We provide a mock version of the DataManager using Mockito
　　@Provides
　　@Singleton
　　public DataManager provideDataManager() {
　　return Mockito.mock(DataManager.class);
　　}
　　}
　　@Singleton
　　@Component(modules = TestApplicationModule.class)
　　public interface TestComponent extends ApplicationComponent {
　　// Empty because extends ApplicationComponent
　　}
　　上面的TestApplicationModule使用Mockito提供了模拟的DataManger对象，TestComponent是ApplicationComponent的继承类，使用了TestApplicationModule作为module，而不是ApplicationModule。这也意味着如果我们在我们的Application类中初始化TestComponent会使用模拟的DataManager对象。