一台不容错过的Java单元测试代码“永动机”_互联网资讯__分享互联网新鲜有趣好玩的事物-云易优站长平台

做者：京东零售陈志良

做为一名京东的软件匠人，我们开发的软件支持着数亿的用户，责任是严重的，因而我们深深地敬畏每一行代码，那若何将我们的失误降到更低呢？那就是单位测试，它会让我们树立对代码的自自信心。为此我们期望能打造一台消费Java单位测试代码的“永动机”，源源不竭地为开发者消费代码，辅助各人高效地做好单位测试，节省精神能投入到更多的营业立异中去。

一、开发者对代码的自自信心来自哪里？

京东跟着营业高速开展，我们创作发明的、承载着数亿用户的、功用强大的系统，在颠末十多年的打磨，也变得日益复杂。做为JD软件开发者，我们是骄傲的，但我们承担的责任也是严重的。我们每一次的立异，就像打造一座下图如许的过山车。我们在为客户带来如斯顶级体验的同时，更重要的是保障每一次的游览都能够平安地着陆。所以我们深深敬畏每一行代码，勤奋将我们的失误降到更低，为营业保驾护航。

然而，营业的迭代速度之快，交付压力之大，做为“过山车”的创作发明者，你能否有以下的履历？

1）每一次上线也像坐了一次过山车呢？

2）你亲手打造的“过山车”，本身能否切身体验过呢？

3）你能否曾对测试同窗说，“你们先上去坐坐看，碰到了问题再下来找我”？

若是你的谜底是：每一次上线也像坐了一次过山车，我们本身打造的“过山车”本身不敢坐，我们的代码要靠测试同窗兜底，那么就申明我们对本身的代码是缺乏自信心的，我们的工做还有待提拔的空间；反之则申明，做为一个开发者你已经相当优良了。

那么若何让我们开发者成立对本身代码的自信心呢，一般来说有两种体例：

1）对“过山车”的每个零件都停止充实的测试，包管每一部门在各类场景下都能够一般工做，对所有的异常也可以处置适当，那便是单位测试。

2）对“过山车”启动前做好充实“查抄”，那便是代码评审，我们邀请其他大佬帮我们把关，及时发现问题。

那两部门工做在开发阶段都是需要的工做，二者缺一不成。

代码评审是借助了外力，单位测试则是内功，靠本身，靠开发者自测来加强对代码的自信心。

本文次要和各人一路切磋单位测试，若何把那单位测试的内功练好。

二、做好单测，慢便是快

关于单位测试的观点，业界同仁理解多有差别，尤其是在营业变革快速的互联网行业，凡是的问题次要有，必需要做吗？做到几适宜？如今没做不也挺好的吗？以至一些大佬们也是存在差别的观点。我们如下先看一组数字：

“在 STICKYMINDS 网站上的一篇名为《 The Shift-Left ApPRoach to Software Testing 》的文章中提到，假设在编码阶段发现的缺陷只需要 1 分钟就能处理，那么单位测试阶段需要 4 分钟，功用测试阶段需要 10 分钟，系统测试阶段需要 40 分钟，而到了发布之后可能就需要 640 分钟来修复。”——来自知乎网站节选

关于那些数字的准确性我们暂且持保留定见。各人能够想想我们现实中碰到的线上问题大要需要消耗几工时，除了要快速找到bug，修复bug上线，还要修复因为bug引发的数据问题，最初还要复盘，看后续若何能制止线上问题，如许下来守旧估量应该不行几人日吧。所以那篇文章做者所做的调研数据可信度仍是很高的，

缺陷发现越到交付流程的后端，其修复成本就越高。

有人说写单测太消耗时间了，会耽误交付时间，其实否则：

1）研测同窗大量的往返交互比编写单测的时间要长的多，集成测试的时间被拖长。

2）没颠末单测的代码bug会多，开发同窗忙于修复各类bug，对代码debug跟踪调试找问题，也要消耗良多精神。

3）后期的线上问题也会需要大量的精神去填补。

若是有了单位测试的代码，且能实现一个较高的行笼盖率，则能够将问题尽可能覆灭在开发阶段。同时有了单测代码的积累，每次代码改动后能够提早发现此次改动引发的其他联系关系问题，上线也愈加安心。单测固然使提测变慢了一些，软件量量愈加有保障，从而节省了后续同窗的精神，从整体看其实效率更高。

所以做好单测，慢便是快。

我们集团手艺委员会大佬们从去年起头也在倡议各人做单位测试，

做为一名开发者我们需要对本身的代码量量负责，

也更能表现我们大厂开发者的工匠精神。

三、若何编写单位测试1、单位测试的支流框架及核心思惟

以下我们先通过一个案例介绍下支流框架的思惟。下图为一个简单的函数施行逻辑，在函数体内间接挪用了函数1、函数2、函数3，间接挪用了函数2.1，此中1和2别离是通俗函数，2.1和3涉及到外部系统挪用，例如JSF、Redis、MySQL等操做，最初返回成果。

代码大致如下：

public class MyObject { @Autowired private RedisHelPEr redisHelper; public MyResult myFunction(InputParam inputParam){ MyResult myResult = new MyResult();//通俗代码块 if(inputParam.isFlag()) { //若是标识表记标帜flag为true，则施行函数1 String f1 = invokeFunction1(); //挪用函数3，函数3封拆了redis中间件操做 String f3 = redisHelper.get(f1); myResult.setResult(f3); } else { //挪用函数2，在函数2内部又挪用长途办事接口2.1 String f2 = invokeFunction2(); myResult.setResult(f2); } return myResult; }

在当下微办事时代，系统间的交互变得愈加日益复杂，以上图例只是简化的例子，现实系统中的上下流外部依赖多达十几个，以至几十个。

在那种情况下，若是过度依赖外部办事就很难保障每次用例施行胜利，会影响到单位测试的施行效果。

所以，当前支流的单位测试框架大都接纳了mock手艺，来屏障对外部办事的依赖，例如：mockito、powermock、Spock等。

图例中2.1和3便是对外部系统的挪用，单位测试代码中需要将其API停止mock，在用例运行时运用mock手艺模仿外部API接口的返回值，详细写法此处不做举例。

要留意的是，利用Mock手艺的框架需要留意两个前提：

1）接口契约是相对不变的（例如redis的api暂时不会发作变革），不然就需要调整测试用例代码以适应最新的接口契约，若是不调整则此单位测试用例代码是无效的。

2）接口挪用是幂等的，同样的入参需要返回不异的成果，不然用例中的断言会失败或者需要对断言停止特殊的处置，例如比力时忽略某些变革的内容（如id、时间等）。

2、第1种单位测试用例的编写计划

接下来写一段基于mockito框架的测试代码，下图中的做法是，开发者编写了一个用例，对外部函数2.1和3停止了mock，然后在测试用例中挪用待测函数，再对返回值停止断言。

示意代码如下：

//创建函数2.1的mock对象 @MockBean private JSFService myJSFService; //创建函数3的mock对象 @MockBean private RedisHelper redisHelper; @Autowired MyObject myObject; @Test public void testMyFunction(InputParameter parameter) { //按照入参mock返回数据 when(myJSFService.invoke(parameter.getX())).thenReturn(X); when(redisHelper.get(parameter.getY())).thenReturn(Y); //期望成果 MyResult expect = new Result(XXX); //现实挪用被测试函数，返回成果 MyResult actual = vmyObject.myFunction(parameter); //断言 Assert.assertEquals(actual.toString(), expect.toString());

运行该用例后，除了待测函数，连带函数1、2一路都被测试到了，在现实中挪用链路会愈加复杂，那么那种写法若何呢？我们做个简要的阐发：

1）长处：用例的编码量较少，实现速度快，一个用例笼盖了3个函数，整个营业施行途径也都被测试到了，别的单测笼盖率的目标不受影响，只要施行过的代码城市被统计到。

2）缺点：若是用例失败，那么去定位问题会较慢，现实项目中链路会愈加复杂，因而排盘问题的时间会大幅度增加，假设问题发作在函数1或2中，那么就需要通过debug跟踪逐渐排查。

那么如许的做法事实若何？到那里若是测试的同窗看到必定会有疑问，如许做的用例跟集成测试阶段的主动化用例有啥区别？是的，从效果上看是一样的，只不外将运行转移到了开发阶段。关于排查和定位问题仍然比力困难，所以从实正的效果动身，不建议只是如许做，请往下看。

3、第2种单位测试用例的编写计划

第2种计划是对每一个办法都写用例代码，每个办法是独立的功用单位，隔离该被测办法的全数依赖，将外部依赖的挪用都做好mock。大致的做法类似下图：

待测函数的测试用例中会涉及到3个mock，别离是函数1、2、3；函数1、函数2也都有本身的测试用例，如许做出来的单位测试效果会更好。在Java中办法是一个最小存在的可测试单位，所以对每个办法停止独立的充实测试，那么组拆后就能够充实保障代码的整体量量，同时也能快速的定位问题，实现快速交付。

目前，业界开发者大多接纳第一种偏集成测试的写法，因其工做量相对较小，在交付压力较大的时候，以至会放弃单位测试,那种情况在互联网行业尤为遍及。在单位测试不敷的情况下，则需要靠加强测试人员的人力来缓解量量问题，但当前营业增长压力垂垂闪现，各大公司都聚焦于内部提效，人力成本控造愈加严酷。打铁还需本身硬，当下我们每一位开发者都需要加强本身的内功修炼。

综合以上两种计划，小结如下：

1）为每个办法写单位测试的测试用例，本办法外部挪用均为mock。

2）编写一小部门集成测试用例，对整体功用停止部门验证，集成测试次要工做仍是交给测试同窗。

四、单位测试应遵照的一些原则

目前行业比力流行的有FIRST原则，整理如下

1）Fast，快速

单位测试用例是施行一个特定使命的一小段代码。与集成测试差别的是，单位测试很小很轻，尽量做到没有收集通信，不施行数据库操做，不启动web容器等耗时操做，使它们能快速施行。开发者在实现应用法式功用时，或者调试bug时，需要频繁去运行单位测试验证成果能否准确。若是单位测试足够快速，就能够省去没必要要浪费的时间，进步工做效率。

2）Independent/Isolated，独立/隔离

单位测试的用例需如果彼此独立的。一个单位测试不要依赖其它单位测试所产生的成果，因为在大大都情况下，单位测试是以随机的挨次运行的。别的，用例代码也不该该依赖和修改外部数据或办事等共享资本，做到测试前后共享资本数据一致，能够用mock或stub的体例对依赖项停止模仿，屏障那些依赖项的不确定性，确保单位测试成果的准确性。

3）Repeatable，可反复

单位测试需要连结运行不变，在差别的计算机、差别的时间点屡次运行，都应该产生不异的成果，若是间歇性的失败，会招致我们不竭的去查看那个测试，不成靠的测试也就失去了意义。

4）Self-Validating，自我验证

单位测试需要接纳Assert相关断言函数等停止自我验证，即当单位测试施行完毕之后就可得知测试成果，全程无需人工介入，不该该在测试完成后做任何额外的人工查抄。留意在单位测试中不要添加任何打印日记的语句，制止通过打印出日记才气判断单位测试能否通过。

5）Thorough/Timely，彻底/及时

在测试一个功用时，我们除了考虑次要逻辑途径以外，还要存眷鸿沟或异常场景。因而在大都时候，我们除了要创建一个具有有效入参的单位测试，还需要筹办其他利用了无效入参的单位测试。例如被测办法入参有一个范畴，从MIN到MAX，那么应该创建额外的单位测试来测试输入为MIN和MAX时能否能准确处置。别的就是及时性，等代码不变运行再来补齐单位测试可能是低效的，最有效的体例是在写好功用函数接口后（实现函数功用前）停止单位测试。

五、单位测试的现状及痛点1、我们通过对行业现状停止调研后，有以下发现：

1）从行业特点看：传统行业软件（ERP、CRM等）单测笼盖率至少到达80%以上，互联网行业软件较低，一般低于50%，大部门没有。

2）从软件特点看：用户量较大的软件（东西类、中间件等）根底软件笼盖率相对较高，至少80%以上，需求变革快的营业类软件相对较低。

3）从开发习惯看：国外开发的软件较高，愈加重视软件的量量，大大都开源软件笼盖率至少都在60%以上。国内开发者大都未养成习惯。

2、单位测试那么重要的工作，为什么在企业中现实中却很难做好呢，次要有以下几个痛点：

1）开发者需要投入更多的工做量：一个应用系统的单位测试代码行数与应用功用代码行数比至少为1:1，复杂应用则更高。凡是来说每提拔1%的单测行笼盖率，则需要编写营业代码1%的测试代码，所以开发者需要付出更多工做量。跟着单位测试笼盖率的提拔，每提拔1%，都需要编写大量的用例，因为后续的用例至少有80%，以至是90%以上的代码运行途径是堆叠的，最坏的情况是增加了一个用例，只多了一行的笼盖。

2）存量代码数量庞大：我们目前存眷的目标还只是核心系统的笼盖率，全量代码笼盖率提拔愈加困难，经年积累的应用中连结代码活泼的数量仍然很庞大，要做现有代码的单位测试编码需要消耗大量人力。

3）单位测试代码容易失效：单位测试的代码需要持续维护，新营业需求引发的代码变动会招致原有的单测代码失效，在营业高速迭代的情况下，没有额外精神投入，要么忽略，要么删除，在那种情况下，很难持续维持一个较高的笼盖率目标。

归根结底，单位测试更大的困难就是成本问题，做好单位测试，我们的开发者需要持续投入大量的精神，而在营业需求高速迭代的情况下，我们该若何破局？谜底就是：主动化手艺

六、单位测试主动化调研

其实，单测主动化手艺的开展至少已有15年以上的汗青，目前支流的手艺是静态代码阐发手艺，它是指无需运行被测代码，仅通过火析或查抄源法式的语法、构造、过程、接口等来查抄法式的准确性，找出代码隐藏的错误和缺陷。次要的代表产物有：EvoSuite、Squaretest等。

上图是EvoSuite东西按照现有被测代码主动生成的测试代码，目前那类产物生成的单测代码的行笼盖率一般能够到达30%摆布，代码越复杂效果越差，它们能够做为简单营业场景的单测代码生成计划。

次要的长处有：纯客户端东西，安拆即可利用，不需复杂设置装备摆设。撑持多种开发平台：撑持idea、eclipse、号令行等多种东西。

次要的不敷：生成代码量量不高、单测笼盖率较低：受限于代码阐发手艺和现实手艺框架的复杂多样，生成的代码量量不高，单测笼盖率较低，只能适用于简单营业场景，且生成的代码需要人工判断有效性。例如订单sendpay如许的标识表记标帜包罗了丰硕的营业语义，则很难通过静态阐发生成有效的用例代码。

七、我们的一些设法与手艺打破1、将录造的数据转化为单位测试用例

基于静态代码阐发局限性，我们需要寻找一个新的标的目的，那么若何可以获得愈加丰硕的营业数据呢，而不是通过一些战略消费数据，前年咱们零售交易研发立异了月光宝盒，完全能够将数据录造下来，于是我们就想到能否能够操纵宝盒录造到的数据，反向生成测试用例呢，以此来实现快速消费单位测试的用例代码。大致的计划思绪如下：

2、标杆验证的效果给了我们自信心

乍一听那个设法有点疯狂，我们针对那个设法做了效果验证，固然还没有到达奇效，但整体思绪得到了查验，事实证明，那个计划固然很难，但是是可行的，以下为Y侧做的标杆案例的测验考试。通过4个标杆的试运行情况阐发，接入一周内，生成代码2.3万行，单测行笼盖率提拔幅度均在30%以上。

3、然而，该计划还其实不完美，我们还有些建议

若是你认真看过前面提到的单位测试原则，针对该计划必然会有疑问，没错，它违背了及时性原则，我们应该在写代码时或者提测前完成啊，测试阶段再录造生成已经晚了。确实，该计划不是完美的，为此我们给出的建议是：

1）针对存量代码，因为目前我们的存量代码数量较大，该计划将会产生较大的效果，开发者只要将录造东西集成到被测应用即可，接入胜利后，若是测试同窗能帮手跑一次全量回归测试更佳，则能够快速生成大量的用例代码，若是测试同窗时间不充沛，则借助测试同窗的日常测试逐步积累数据，颠末一两周后也能获得大量用例代码。

2）关于新开发代码，在开发者完成编码后的自测阶段，由开发者本身当地运行法式停止自测、录造，也能帮忙我们生成一多量用例，然后能够基于生成的用例，再通过复造、手工调整停止快速扩大用例，从而包管单位测测的及时性。

3）特殊营业场景处置，关于鸿沟或异常用例很难录造到，则能够通过手工复造用例，再修改用例数据，来扩大用例，那种体例比纯手工编写仍是快良多，尤其是mock对象十分复杂的时候，用该计划能够在1分钟内即可基于已有用例扩展一个新用例。

4、生成的单位测试用例是什么样子

下面举一个生成单位测试用例代码的现实例子，该例子基于Mockito框架，每一个用例办法对应一个JSON文件，JSON文件中存储着用例运行时需要的收支参、全数外部挪用的数据，用例代码和数据全数由东西主动生成，生成的大部门代码都是在帮忙开发者将录造的数据组拆Mock对象，那部门工做量在现实开发中是更大的，因而能够大幅度减小开发者本身纯手工编码工做。当需要手工扩大用例时，只需要将用例办法和数据文件复造一份，再对用例数据做出调整即可造做出新的用例。