作者：京东零售 陈志良

作为一名京东的软件匠人，咱们开发的软件支撑着数亿的用户，职责是严重的，因而咱们深深地敬畏每一行代码，那怎么将咱们的失误降到最低呢？那便是单元测验，它会让咱们树立对代码的自决心。为此咱们希望能打造一台出产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目标，这部分作业量在实践开发中是最大的，因而能够大幅度减小开发者自己纯手艺编码作业。当需求手艺扩大用例时，只需求将用例办法和数据文件仿制一份，再对用例数据做出调整即可制作出新的用例。

数据文件样例：
/artt/StockStatusReOccupySplitServiceImpl1#HpCm.json

5、咱们所遇到的技能挑战

咱们遇到了许多技能难点，因为根据宝盒录制的数据在复原代码时信息还不足，需求添加更多的录制信息与特别使用场景处理，首要难点有：

1）结构化数据的录制与复原，杂乱泛型的复原、杂乱目标的序列化和反序列化

2）根据动态署理技能完结代码的特别处理，如mybatis、JSF

3）用例的采样操控，重复用例的识别与剔除，

4）用例成果断语的多样性，需求丰厚的比对战略

期间涉及到了许多的底层技能研究，截至现在咱们仍然有许多技能点需求攻克。例如，咱们正在做的使用接入提高，将Spring AOP的办法用agent+ASM办法进行替换，完结代码增强在不重启服务的状况下动态挂载、卸载，也进一步下降接入本钱，减少对使用的入侵。

八、单测主动化渠道的架构



全体分为三部分：

1）录制端，选用月光宝盒为基座，根据Spring AOP和ASM字节码增强agent技能，开发者在使用内部进行集成，一同在使用发动中添加agent署理脚本设置。

2）渠道端，采集到的数据将被发往渠道端，渠道端首要负责使用注册、录制用例的统一管理等，并为生成端供给用例抽取服务。

3）生成端，以idea插件、命令行脚本的方式，为用户的使用生成代码，而且按照每个用例掩盖事务代码的行号进行去重。最终生成的代码提交到代码库，bamboo集成获取代码进行单测运转与目标的采集。

九、单测渠道的共建与接入

单元测验主动化技能是当今软件范畴的一个难题，职业的开发者也都在活跃寻求打破

咱们乐意做一只啄木鸟

帮助开发者找到代码里的虫子

经过主动化技能树立单测的决心

但啄木鸟还做不到全面主动化

咱们不要因为它的存在而变得松懈

每位开发者仍然要发扬：

工匠精力，以人为本，东西为辅

在提测前轻松做好单元测验