几点说明： 代码中的 //<== 表示跟上面的相比，这是新增的，或者是修改的代码，不知道怎么样在代码块里面再强调几行代码 T_T。。。 很多时候，为了避免中文歧义，我会用英文表述 在第一篇文章里面我们提到，返回类型为 void 方法的单元测试方式，往往是验证里面的某个对象的某个方法是否得到了调用。在那篇文章里面，我举的例子是 activity 里面的一个 login 方法： public void login() { String username = ...//get username from username EditText String password = ...//get password…
大家好，我是蘑菇街支付金融部门的邹勇，花名叫小创。今天很高兴跟大家分享一下安卓的单元测试在蘑菇街支付金融的实践。下面，我们从为什么开始。 为什么要写单元测试 首先要介绍为什么蘑菇街支付金融这边会采用单元测试的实践。说起来比较巧，刚开始的时候，只是我一个人会写单元测试。后来老板们知道了，觉得这是件很有价值的事情，于是就叫我负责我们组的单元测试这件事情。就这样慢慢的，单元测试这件事情就成了我们这边的正常实践了。再后来，在公司层面也开始有一定的推广。 要说为什么要写单元测试的话，我相信大部分人都能承认、也能理解单元测试在保证代码质量，防止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，然后上传到模拟器或真机上，再运行相关的代码，速度相对来说慢很多。 单元测试的定义相信大家都知道，就是为我们写的某一个代码单元（比如一个方法）写的测试代码。一个单元测试大概可以分为三个部分： setup：即new 出待测试的类，设置一些前提条件 执行动作：即调用被测类的被测方法，并获取返回结果 验证结果：验证获取的结果跟预期的结果是一样的 然而一个类的方法分两种，一种是有返回值的方法。一种是没有返回值的方法，即void方法。对于有返回值的方法，固然测试起来是很容易的，但是对于没有返回值的方法，该怎么测试呢？这里的关键是，怎么样获取这个方法的“返回结果”? 这里举一个例子来说明一下，顺便澄清一个十分常见的误解。比如说有一个Activity，管他叫DataActivity，它有一个public void loadData()方法, 会去调用底层的DataModel类，异步的执行一些网络请求。当网络请求返回以后，更新用户界面。…
我们写单元测试，一般都会用到一个或多个单元测试框架，在这里，我们介绍一下 JUnit4 这个测试框架。这是 Java 界用的最广泛，也是最基础的一个框架，其他的很多框架，包括我们后面会看到的 Robolectric，都是基于或兼容 JUnit4 的。 然而首先要解决的问题是。。。 为什么要使用单元测试框架 或者换句话说，单元测试框架能够为我们做什么呢？ 从最基本的开始说起，假如我们有这样一个类： public class Calculator { public int add(int one, int another) { // 为了简单起见，暂不考虑溢出等情况。 return one + another; }…
今天早上8点半坐到桌子前，打开电脑，看了几分钟体育新闻，做其他一些准备工作，到9点开始真正开始着手写这篇文章。于是开始google，找资料，打算列一大段冠冕堂皇的理由，来说明为什么要写单元测试，比如： 对软件质量的提升 方便重构 节约时间 提升代码设计 。。。 等等等等。 然而我发现上面提到的几点，都不是很好解释。首先，我并没有具体的数据，来说明有了单元测试，我们的app crash率降了多少，bug少了多少等等。这种东西首先我们没有去衡量，因为单元测试的增加是循序渐进的，每个版本的迭代增加一点点。很难，我们也没有，去前后对比。再次，crash率的降低和bug的减少，也难以证明就是单元测试的作用。另外，像重构这种理由，怎么举例证明呢？例子小了显得没有意义，例子大了写起来很困难，读起来也困难。而关于节约时间，我也没有测量过，这个恐怕也很难去测量。只能从理论上去说明，为什么可以节约时间，恐怕也很难有说服力的去论述。同样的，对于代码设计的提升，也很难有力的去证明。 更重要的原因是，上面提到的种种好处，好像其实并不是我之所以要写单元测试的直接原因，更多的，他们像是一种结果。所以如果从列举和证明单元测试的好处这个角度去说明为什么要写单元测试的话，我感觉甚至很难说服我自己。 那就从自身的经历和感受去说说，我为什么要写单元测试吧。其实我之所以要写单元测试，或者说这么喜欢单元测试这种写代码的方式，是出于我自身的原因，或者说因为自身的一些缺点，让我走上了单元测试这条路，而且再也不想回头。 我为什么写单元测试 首先，是因为我不够自信 我相信大家都有接手，或者说参与到一个新项目的经历，也许是因为换了工作，也许是因为职位调动，或其他原因。当我拿到一个新项目的时候，会有一种诚惶诚恐的感觉，因为一时间比较难理清楚整个app的结构是怎么划分的，各部分各模块之间又是什么样的关系。我怕我改了某一个地方，结果其他一个莫名其妙的地方的受到了影响，然后导致了一个bug。这对于用户群大的app，尤其严重。所以，那种时候就会希望，如果我改了某个地方，能有个东西告诉我，这个改动影响到哪些地方，这样改是不是有问题的，会不会导致bug。虽然我可以把app启动起来，看看是不是能正常工作，然而一种case能工作，并不代表所有影响到的case都能工作。尤其是在不知道有哪些地方用到了的情况下，我更加难以去遍历所有用到的地方，一个一个去验证这个改动有没有问题。哪怕我知道所有的case，这也是一个很痛苦很费时间的过程，而且很多的外部条件也很难满足，比如说需要什么样的网络条件，需要用户是会员等等。 在这种情况下，单元测试是才是最好的工具。首先，单元测试只是针对一个代码单元写的测试，保证一个代码单元的正确性总比保证整个app的正确性容易吧？遍历一个方法的所有参数和输出情况总比遍历一个app的所有用户场景容易吧？跑一次单元测试总比运行一次app快吧？ 因此，在改现有的代码之前，我会先对要改的代码单元做好隔离，写好测试，再去改，改好以后跑一边单元测试，验证他们依然是通过的，这时候我才有信心，将代码合并进去。 同样的情况会发生在重构的时候，我是一个对烂代码不大有忍受能力的人，看到不好的代码，我会忍不住想要去重构，不然的话，没有办法写新的代码。而重构就会有风险。因为我不够自信，重构的时候，也会有一种诚惶诚恐的感觉。这时候如果有完备的单元测试的话，我就能知道我的这次重构到底破坏了哪些地方，是不是对的，这样相对来说，就会放心的多了。 因此，想用单元测试来保证代码的正确性，这个是我喜欢写单元测试的重要原因之一。 再次，是因为我没有耐心 对于有一定经验，有一定代码思想的人来说，当他拿到一个新的需求，他会先想想代码的结构，应该有那些类，那些组件，什么责任应该划分到哪里去，然后才开始动手写代码，这个是很自然的一个思维过程。然而在不写单元测试的情况下，我们可能要把整个feature都做完整，从model到controller(或Presenter、ViewModel）到view到util等等，一整套流程做下来，到最后才可能运行起来看看是不是对的，有的时候哪怕所有代码都写完了，也不一定能验证是不是对的，比如说后台还没有ready等等。总之，在没有单元测试的情况下，我们需要等到最后一刻才能手动验证代码是不是对的，然后发现原来这里错了一点，那里少了一点，然后一遍一遍的把app运行起来，改一点运行一遍。。。 当我开始写单元测试之后，我发现这个过程实在是太漫长了，我喜欢写完一部分功能独立的代码，就能立刻看到他们是不是正确的。如果不是的话，我可以立刻就改正，而不用等到所有代码都写完整。要达到这点，那就只有写单元测试了。 当然，哪怕有单元测试，最后还是要做一遍手动测试工作，然而因为前面我已经保证每一个单元都是对的，最后只不过是验证每一部分都是正确的串联起来了而已，这点相对来说，是很容易的。所以最后所需要的手动测试，可以少很多，顺利很多，也简单得多。 最后，是因为我懒 如前所述，如果没有单元测试的话，那就只有手工测试，把app运行起来，如果有错的话，改一点东西，再运行起来。。。这个过程太漫长太痛苦，对于一个很懒的人来说，如果能写代码来代替手工测试，每次写完代码只需要按一次快捷键，就可以直接在IDE里面看到结果，那是多爽的一件事！所以冲着这点，我也不想回头。 我记得上一次使用“把app运行起来”这种开发方式，还是因为调试一个动画效果。因为动画效果是很难单元测试的，那就只有改一点代码，跑一边app，觉得不对，再改一点，跑一边，这样来来回回反反复复，那感觉真是。。。 单元测试给我带来了什么 前面讲了为什么我要写单元测试的原因，接下来讲讲用了单元测试这种写代码的方式以后，给我带来什么样的好处。这根前面讲的“原因”有部分重合的地方，然而也有不一样的地方。 更快的结果反馈 这点前面讲过了，有单元测试的帮助，我可以写完一个独立的代码单元，就立刻验证它的正确性，这跟需要完成所有代码再把app运行起来手动测试相比，是一个更快的反馈循环，能更快的发现代码是否正确，也更快的得到一种成就感。 更少的bug，或者说更快的发现bug…
这是一系列安卓单元测试的文章，目测主要会 cover 以下的主题： 什么是单元测试 为什么要做单元测试 JUnit Mockito Robolectric Dagger2 一个具体的app例子实践 神秘的bonus 什么是单元测试 首先需要介绍一下什么是单元测试。很多人像我一样，本科并不是计算机专业出身的，如果在职的公司不要求做单元测试的话，可能对这个词并没有一个确切的概念。而即使是计算机专业出身，如果毕业以后写的不多的话，可能对这个词的含义也不是很清楚。从名字上看，单元测试是为了测试某一个代码单元而写的测试代码。但是什么叫“一个代码单元”呢？是一个模块、还是一个类、还是一个方法（函数）呢？不同的人、不同的语言，都有不同的理解。一般的定义，尤其是是在OOP领域，是一个类的一个方法。在此，我们也这样理解：单元测试，是为了测试某一个类的某一个方法能否正常工作，而写的测试代码。 我们举一个例子说明一下，假如你有一个类，定义如下： public class Calculator { public int add(int one, int another) { //为了简单起见，暂不考虑溢出等情况。 return one + another;…