Categories
未分类

Android单元测试(四):Mock以及Mockito的使用

几点说明: 代码中的 //<== 表示跟上面的相比,这是新增的,或者是修改的代码,不知道怎么样在代码块里面再强调几行代码 T_T。。。 很多时候,为了避免中文歧义,我会用英文表述 在第一篇文章里面我们提到,返回类型为 void 方法的单元测试方式,往往是验证里面的某个对象的某个方法是否得到了调用。在那篇文章里面,我举的例子是 activity 里面的一个 login 方法: public void login() { String username = …//get username from username EditText String password = …//get password from password EditText //do other operation like validation, etc … mUserManager.performLogin(username, password); } 对于这个 login 方法的单元测试,应该是调用 Activity 里面的这个 login 方法,然后验证mUserManager的performLogin方法得到了调用。但是如果使用 Activity,我们就需要用到Robolectric框架,然而我们到目前为止还没有讲到 Robolectric 的使用。所以在这篇文章中,我们假设这段代码是放在一个 Presenter(LoginPresenter)里面的,这个是MVP 模式里面的概念,这个LoginPresenter是一个纯 […]

Categories
未分类

Android单元测试在蘑菇街支付金融部门的实践

大家好,我是蘑菇街支付金融部门的邹勇,花名叫小创。今天很高兴跟大家分享一下安卓的单元测试在蘑菇街支付金融的实践。下面,我们从为什么开始。 为什么要写单元测试 首先要介绍为什么蘑菇街支付金融这边会采用单元测试的实践。说起来比较巧,刚开始的时候,只是我一个人会写单元测试。后来老板们知道了,觉得这是件很有价值的事情,于是就叫我负责我们组的单元测试这件事情。就这样慢慢的,单元测试这件事情就成了我们这边的正常实践了。再后来,在公司层面也开始有一定的推广。 要说为什么要写单元测试的话,我相信大部分人都能承认、也能理解单元测试在保证代码质量,防止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类,异步的执行一些网络请求。当网络请求返回以后,更新用户界面。 这里的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 […]

Categories
未分类

Android单元测试(三):JUnit单元测试框架的使用

我们写单元测试,一般都会用到一个或多个单元测试框架,在这里,我们介绍一下 JUnit4 这个测试框架。这是 Java 界用的最广泛,也是最基础的一个框架,其他的很多框架,包括我们后面会看到的 Robolectric,都是基于或兼容 JUnit4 的。 然而首先要解决的问题是。。。 为什么要使用单元测试框架 或者换句话说,单元测试框架能够为我们做什么呢? 从最基本的开始说起,假如我们有这样一个类: public class Calculator { public int add(int one, int another) { // 为了简单起见,暂不考虑溢出等情况。 return one + another; } public int multiply(int one, int another) { // 为了简单起见,暂不考虑溢出等情况。 return one * another; } } 如果不用单元测试框架的话,我们要怎么写测试代码呢?我们恐怕得写出下面这样的代码: public class CalculatorTest { public static void main(String[] args) […]

Categories
未分类

Android单元测试(二):再来谈谈为什么

今天早上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 正如上面所说,我们没有做这样的前后统计,来证明有了单元测试以后,我们app的bug少了多少。然而,我自己的经验是,我已经不知道多少次以为只是做了一点小改动,不会有任何问题,结果一跑单元测试,发现还是改出问题来了。从这点来说,单元测试帮助我发现了不少问题,至少是更快的发现了问题。很多时候,这些问题是因为不小心疏忽了而导致的。然而话说回来,大部分bug不都是因为不小心疏忽了,很多情况考虑到,或者是考虑错了而导致的吗? 你或许会觉得,自己很厉害很专业,一定不会有这种“疏忽”,写的代码一定是没有bug的。然而事实是,再厉害的人,都有状态不好的时候,都有情绪不高的时候,都有感觉比较累的时候,都会受到或多或少外界的干扰,这种时候都是很容易犯错的。这个跟厉不厉害,专不专业其实没有关系。李世石多么专业,在跟AlphaGo比赛的时候,不是依然会失误,会犯错吗?这个时候如果有那么一层保障,来防止你不小心犯错,岂不是更好的一件事情? ### 节约时间 对于安卓开发来说,一遍一遍的运行app,再执行相应的用户操作,看界面是否显示正确的结果,通过这种方式来测试自己的新代码、重构是否是正确的,这是非常浪费时间的一件事情,而且效果还不好。有了单元测试,我现在开发过程中几乎已经不用把app运行起来了,速度相对来说快多了。 此外,因为单元测试能帮我减少bug,从而也减少了调试bug,fix bug的时间。一个切身感受是,自从开始写单元测试以后,我启动AndroidStudio的debugger的次数明显减少了。这也是单元测试节约时间的地方。 当然,这个结论也是自我感觉的结果。写单元测试需要时间,这也是不能否认的事情,至于有单元测试是否真的更快,快了多少,我没有具体的统计数据,所以很难给出一个确切的答案。 这里需要重点说一下的是,你为新代码写的单元测试,不仅仅是能在目前你这次写新代码的时候起了作用,它的作用更体现在以后重构代码的时候,你可以很快速,很安全的进行重构。这点往往大家会忽略,所以会觉得在单元测试上花费的时间“不值得”。 ### 更好的设计 当你为自己的代码写单元测试的时候,尤其是采用TDD的方式,你会很自觉地把每个类写的比较小,功能单一,这是软件设计里面很重要的SRP原则。此外,你能把每个功能职责分配的很清楚,而不是把一堆代码都塞到一个类里面(比如Activity)。你会不自觉的更偏向于采用组合,而不是继承的方式去写代码。这些都是很好的一些代码实践。 至于为什么TDD能够改善代码的设计,网上有很多的文章去分析和论证这个结论。我看到比较印象深刻的一句话是(具体在哪看的搜不出来了):当你TDD的时候,你是从一开始,就从一个代码的使用者,或者说维护者的角度,去写你的代码。这样写出来的代码,自然会有更好的设计。 ### 更强的自信心 有单元测试来保证你的代码是对的,这对于你写代码、发布代码、重构都提供了信心保证,没有那么多的担心,从而工作起来也更快乐更开心。做人呐,最重要的是开心。。。 ## 没有时间写单元测试? 前面大概讲了讲我为什么要写单元测试,以及单元测试给我带来的好处,这些其实如果大家去google […]

Categories
未分类

Android单元测试: 首先,从是什么开始

这是一系列安卓单元测试的文章,目测主要会 cover 以下的主题: 什么是单元测试 为什么要做单元测试 JUnit Mockito Robolectric Dagger2 一个具体的app例子实践 神秘的bonus 什么是单元测试 首先需要介绍一下什么是单元测试。很多人像我一样,本科并不是计算机专业出身的,如果在职的公司不要求做单元测试的话,可能对这个词并没有一个确切的概念。而即使是计算机专业出身,如果毕业以后写的不多的话,可能对这个词的含义也不是很清楚。从名字上看,单元测试是为了测试某一个代码单元而写的测试代码。但是什么叫“一个代码单元”呢?是一个模块、还是一个类、还是一个方法(函数)呢?不同的人、不同的语言,都有不同的理解。一般的定义,尤其是是在OOP领域,是一个类的一个方法。在此,我们也这样理解:单元测试,是为了测试某一个类的某一个方法能否正常工作,而写的测试代码。 我们举一个例子说明一下,假如你有一个类,定义如下: public class Calculator { public int add(int one, int another) { //为了简单起见,暂不考虑溢出等情况。 return one + another; } } 那么为了测试这个Calculator类的add()方法,我们可以写如下的单元测试代码: public class CalculatorTest { public void testAdd() throws Exception { Calculator calculator = new Calculator(); int sum = calculator.add(1, 2); Assert.assertEquals(3, sum); […]