蘑菇街支付金融Android单元测试实践

　　本文为『移动前线』群在4月23日的分享总结整理而成，转载请注明来自『移动开发前线』公众号。

　　嘉宾介绍

　　邹勇(网名小创)蘑菇街支付金融资深安卓开发工程师。自毕业以来一直从事Android开发工作，先后工作于创新工厂、微策略以及蘑菇街。对单元测试和TDD情有独钟。

　　大家好，我是蘑菇街支付金融部门的邹勇，花名叫小创。今天很高兴跟大家分享一下安卓的单元测试在蘑菇街支付金融的实践。下面，我们从为什么开始。

　　为什么要写单元测试

　　首先要介绍为什么蘑菇街支付金融这边会采用单元测试的实践。说起来比较巧，刚开始的时候，只是我一个人会写单元测试。后来老板们知道了，觉得这是件很有价值的事情，于是就叫我负责我们组的单元测试这件事情。就这样慢慢的，单元测试这件事情就成了我们这边的正常实践了。再后来，在公司层面也开始有一定的推广。

　　要说为什么要写单元测试的话，我相信大部分人都能承认、也能理解单元测试在保证代码质量，防止bug或尽早发现bug这方面的作用，这可能是大家觉得单元测试最大的作用。然而我觉得，除了这方面的作用，单元测试还能在很大程度上改善代码的设计，同时还能节约时间，让人工作起来更自信、更开心，以及其他的一些好处。这些都是我的切身感受，我相信也是多数真正实践过单元测试的人的切身感受，而不是为了宣传这个东西而说的好听的大话。

　　说到节约时间，大家可能就会好奇了，写单元测试需要时间，维护单元测试代码也需要时间，应该更费时间才对啊?

　　这就是在开始分享之前，我想重点澄清的一点，那就是，单元测试本身其实不会占用多少时间，相反，还会节约时间。只是：

　　学习如何做单元测试需要时间;

　　在一个没有单元测试的项目中加入单元测试，需要一定的结构调整的时间，因为一个有单元测试跟没有单元测试的项目，结构上还是有较大不同的。

　　打个比方，开车这件事情，需要很多时间吗?我相信很少人会说开车这件事情需要很多时间，而是：

　　学习开车，需要一定的时间;

　　如果路面不平的话，那么修路需要一定的时间。单元测试也是类似的情况。

　　那为什么说单元测试可以节约时间呢?简单说几点：

　　如果没有单元测试的话，就只能把app运行起来测试，这比运行一次单元测试要慢多了。

　　尽早发现bug，减少了debug和fixbug的时间。

　　重构的时候，大大减少手动验证重构正确性的时间。

　　所以，我希望大家能去掉"没时间写单元测试"这个印象，如果工作上安排太紧，没有时间学习如何做单元测试的话，可以自己私底下学，然后在慢慢应用到项目中。

　　单元测试简单介绍

　　接下来介绍我们这边是怎么做安卓单元测试的。首先澄清一下概念，在安卓上面写测试，有很多技术方案。有JUnit、 Instrumentation test、Espresso、UiAutomator等等，还有第三方的Appium、Robotium、Calabash等等。我们现在讲的是使用 JUnit和其他的一些框架，写可以在我们开发环境的JVM上面直接运行的单元测试，其他的几种其实都不属于单元测试，而是集成测试或者叫 Functional test等等。这两者明显的不同是，前者可以直接在开发用的电脑，或者是CI上面的JVM上运行，而且可以只运行那么一小部分代码，速度非常快。而后者必须要有模拟器或真机，把整个project打包成一个app，然后上传到模拟器或真机上，再运行相关的代码，速度相对来说慢很多。

　　单元测试的定义相信大家都知道，就是为我们写的某一个代码单元(比如一个方法)写的测试代码。一个单元测试大概可以分为三个部分：

　　setup：即new 出待测试的类，设置一些前提条件

　　执行动作：即调用被测类的被测方法，并获取返回结果

　　验证结果：验证获取的结果跟预期的结果是一样的

　　然而一个类的方法分两种，一种是有返回值的方法。一种是没有返回值的方法，即void方法。对于有返回值的方法，固然测试起来是很容易的，但是对于没有返回值的方法，该怎么测试呢?这里的关键是，怎么样获取这个方法的“返回结果”?

　　这里举一个例子来说明一下，顺便澄清一个十分常见的误解。比如说有一个Activity，管他叫DataActivity，它有一个public void loadData()方法, 会去调用底层的DataModel类，异步的执行一些网络请求。当网络请求返回以后，更新用户界面。

原文转自： http://www.infoq.com/cn/articles/mogujie-android-unit-testing