这是我在InfoQ组织的移动开发前线微信群里面做的一次分享，发到简书上面一份，希望给在简书有需要的读者也能提供一点帮助，以下是原文：
　　大家好，我是蘑菇街支付金融部门的小创。很高兴跟大家分享一下安卓的单元测试在蘑菇街支付金融的实践。下面，我们从为什么开始。
　　为什么要写单元测试？
　　首先要介绍为什么蘑菇街支付金融这边会采用单元测试的实践。说起来比较巧，刚开始的时候，只是我一个人会写单元测试。后来老板们知道了，觉得这是件很有价值的事情，于是叫我负责我们组的单元测试这件事情。这样慢慢的，单元测试这件事情成了我们这边的正常实践了。再后来，在公司层面也开始有一定的推广。
　　要说为什么要写单元测试的话，我相信大部分人都能承认、也能理解单元测试在保证代码质量，防止bug或尽早发现bug这方面的作用，这可能是大家觉得单元测试大的作用。然而我觉得，除了这方面的作用，单元测试还能在很大程度上改善代码的设计，同时还能节约时间，让人工作起来更自信、更开心，以及其他的一些好处。这些都是我的切身感受，我相信也是多数真正实践过单元测试的人的切身感受，而不是为了宣传这个东西而说的好听的大话。
　　说到节约时间，大家可能会好奇了，写单元测试需要时间，维护单元测试代码也需要时间，应该更费时间才对啊？
　　这是在开始分享之前，我想重点澄清的一点，那是，单元测试本身其实不会占用多少时间，相反，还会节约时间。只是：1. 学习如何做单元测试需要时间；2. 在一个没有单元测试的项目中加入单元测试，需要一定的结构调整的时间，因为一个有单元测试跟没有单元测试的项目，结构上还是有较大不同的。
　　打个比方，开车这件事情，需要很多时间吗？我相信很少人会说开车这件事情需要很多时间，而是：1. 学习开车，需要一定的时间；2. 如果路面不平的话，那么修路需要一定的时间。单元测试也是类似的情况。
　　那为什么说单元测试可以节约时间呢？简单说几点：1. 如果没有单元测试的话，只能把app运行起来测试，这比运行一次单元测试要慢多了。2. 尽早发现bug，减少了debug和fixbug的时间。3. 重构的时候，大大减少手动验证重构正确性的时间。
　　所以，我希望大家能去掉"没时间写单元测试"这个印象，如果工作上安排太紧，没有时间学习如何做单元测试的话，可以自己私底下学，然后在慢慢应用到项目中。
　　单元测试简单介绍，以及void方法怎么测
　　接下来介绍我们这边是怎么做安卓单元测试的。首先澄清一下概念，在安卓上面写测试，有很多技术方案。有JUnit、Instrumentation test、Espresso、UiAutomator等等，还有第三方的Appium、Robotium、Calabash等等。我们现在讲的是使用JUnit和其他的一些框架，写可以在我们开发环境的JVM上面直接运行的单元测试，其他的几种其实都不属于单元测试，而是集成测试或者叫Functional test等等。这两者明显的不同是，前者可以直接在开发用的电脑，或者是CI上面的JVM上运行，而且可以只运行那么一小部分代码，速度非常快。而后者必须要有模拟器或真机，把整个project打包成一个app，然后上传到模拟器或真机上，再运行相关的代码，速度相对来说慢很多。
　　单元测试的定义相信大家都知道，是为我们写的某一个代码单元（比如一个方法）写的测试代码。一个单元测试大概可以分为三个部分：
　　1、setup：即new 出待测试的类，设置一些前提条件
　　2、执行动作：即调用被测类的被测方法，并获取返回结果
　　3、验证结果：验证获取的结果跟预期的结果是一样的
　　然而一个类的方法分两种，一种是有返回值的方法。一种是没有返回值的方法，即void方法。对于有返回值的方法，固然测试起来是很容易的，但是对于没有返回值的方法，该怎么测试呢？这里的关键是，怎么样获取这个方法的“返回结果”?
　　这里举一个例子来说明一下，顺便澄清一个十分常见的误解。比如说有一个Activity，管他叫DataActivity，它有一个public void loadData()方法， 会去调用底层的DataModel类，异步的执行一些网络请求。当网络请求返回以后，更新用户界面。
　　这里的loadData()方法是void的，它该怎么测试呢？一个直接的反应可能是，调用loadData()方法(当然，实际可能是通过其他事件触发)，然后一段时间后，验证界面得到了更新。然而这种方法是错的，这种测试叫集成测试，而不是单元测试。因为它涉及到很多个方面，它涉及到DataModel、网络服务器，以及网络返回正确时，DataActivity内部的处理，等等。集成测试固然有它的必要性，但不是我们应该关注的地方，也不是有价值的地方。我们应该关注的是单元测试。关于这一点，有一个Test Pyramid的理论：

　　Test Pyramid理论基本大意是，单元测试是基础，是我们应该花绝大多数时间去写的部分，而集成测试等应该是冰山上面能看见的那一小部分。
　　那么对于这个case，正确的单元测试方法，应该是去验证loadData()方法调用了DataModel的某个请求数据的方法，同时传递的参数是正确的。“调用了DataModel的方法，同时参数是。。。” 这个才是loadData()这个方法的“返回结果”。
　　Mock的概念以及Mockito框架
　　要验证某个对象的某个方法得到调用了，涉及到mock的使用。这里对mock的概念做个简单介绍，以免很多同学不熟悉，mock是创建一个虚假的、模拟的对象。在测试环境下，用来替换掉真实的对象。这样能达到两个目的：1. 可以随时指定mock对象的某个方法返回什么样的值，或执行什么样的动作。 2. 可以验证mock对象的某个方法有没有得到调用，或者是调用了多少次，参数是什么等等。
　　要使用mock，一般需要使用mock框架，目前安卓常用的有两个，Mockito和JMockit。两者的区别是，前者不能mock static method和final class、final method，后者可以。我们依然采用的是Mockito，原因说起来惭愧，是因为刚开始并不知道JMockit这个东西，后来查了一些资料，看过很多对比Mockito和JMockit的文章，貌似大部分还是很看好JMockit的，只是有一个问题，那是跟robolectric的结合也有一些bug，同时使用姿势跟Mockito有较大的不同，因此一直没有抽时间去实践过。这个希望以后能够做进一步的调查，到时候在给大家分享一下使用感受。
　　但是使用Mockito，有一个问题，那是static method和final class、final method没有办法mock，对于这点如何解决，我们稍后会介绍到。
　　在测试环境中使用mock：依赖注入
　　接下来的一个问题是，如何在测试环境下，把DataModel换成mock的对象，而正式代码中，DataModel又是正常的对象呢？
　　这个问题也有两种解决方案，一是使用专门的testing product flavor；二是使用依赖注入。第一种方案是用一个专门的product flavor来做testing，在这个testing flavor里面，里面把需要mock的类写一份mock的implementation，然后通过factory提供给client，这个factory的接口在testing flavor和正式的flavor里面是一样的，在跑testing的时候，专门使用这个testing flavor，这样通过factory得到的是mock的类。这种情况看起来很简单，但其实很不灵活，因为只有一种mock实现；此外，代码会变得很丑陋，因为你需要为每一个dependency提供一个factory，会觉得很刻意；再者，多了一个flavor，很多gradle任务都会变得很慢。关于这种方案，可以参考这个视频。
　　因此，我们用的是第二种，依赖注入。先简单介绍一下依赖注入这个模式，他的基本理念是，某一个类（比如说DataActivity），用到的内部对象（比如说DataModel）的创建过程不在DataActivity内部去new，而是由外部去创建好DataModel的实例，然后通过某种方式set给DataActivity。这种模式应用是非常广泛的，尤其是在测试的时候。为了更方便的做依赖注入，如今有很多框架专门做这件事情，比如RoboGuice、Dagger、Dagger2等等。我们用的是Dagger2，理由很简单，这是目前好用的DI框架。
　　关于Dagger2的文章，之前我们群里也分享了不少，但是好像我并没有看到讲述没有关于如何在测试环境下使用Dagger2的文章，这个还是略感遗憾的。离开单元测试，使用依赖注入少了很有说服力的一个理由。