柳州网站建设之基于链路思想的SpringBoot单元测试快速写法

本文更偏向实践而非方法论，所提及的SpringBoot单元测试写法亦并非官方解，仅仅是笔者自身觉得比较方便、效率较高的一种写法。每个团队甚至团队内的每位开发可能都有自己的写法习惯和风格，只要能实现单元测试的效果，就没必要纠结于写法的简单抑或复杂。这里也欢迎各位大佬们发表看法或分享自己的单测心得，帮助像笔者这样的新人快速成长。

一   为什么要写单元测试？

测试是Devops上极重要的一环，但大多数开发的眼光都停留在集成测试这一环——只要能联调成功，那么我这次准备上线的特性一定是没问题的。

老实承认，我曾经是这样的可能现在也还是这样。作为非科班出身的笔者，研究生毕业后就立即进入了同在杭州的xx厂，先后参与了内部Devops平台建设和xx云Paas项目开荒，在这两个项目中，开发 > 测试是很正常的场景，甚至部分测试也是原开发友情客串的：由于缺少专业的测试人员，开发往往需要兼顾集成测试甚至是线上测试的活儿。为了提高效率，我将一部分常用的测试用例维护在了内部的自动化测试平台上。即便如此，我仍能清晰地感觉到，测试所能覆盖的场景屈指可数，以至于每次自信地上线大特性后，都会因一些奇怪的问题而定位到大半夜。幸亏后面遇到了一位资深大佬，在code review时，他直接点出我不写单元测试的坏习惯，并用自身惨痛的线上教训反复强调单测的重要性。

当然上述只是我的亲身经历，勉强作为日常闲聊的谈资。如果想要深入理解单元测试的重要性，推荐Google上搜索the importance of unit test关键字，可以感受下不同国家、不同领域的程序员对单元测试的不同理解，想必能有更大的收获。

二   为什么推荐链路思想？

深入接触单元测试，开发难免会遇到以下场景：

应该如何设计测试用例？

应该如何编写测试用例？

测试用例的质量该如何判定？

刚开始学习写单元测试，我也曾参考并尝试过网上五花八门的写法。这些写法可能用到了不同的单测框架，也可能侧重了不同的代码环节(例如特定的某个service方法)。一开始我为自己能够熟练使用多种单测框架而沾沾自喜，但随着工作的推进，我逐渐意识到，单元测试中重要的并不是框架选型，而是如何设计一套优秀的用例。之所以用"一套"而不是"一个"，是因为在我们的业务代码中，逻辑往往并非"一帆风顺"，有许多if-else会妆点我们的业务代码。显然对于这类业务代码，"一个"测试用例无法完全满足所有可能出现的场景。如果为了偷懒，尝试仅仅用"一个"用例去覆盖主流程，无异于给自己埋了个雷——线上场景可没"一个"用例这么简单！

我开始专注于测试用例的设计，从输入输出开始，重新审视曾经开发过的代码。我发现，如果将某个controller方法作为入口，那这一套业务流程可以当做一条链路，而上下文中所关联的service层、dao层、api层的各方法都可以作为链路上的各环节。通过绘制链路图，将各环节根据是否关联外部系统大致分成黑、白两类，整套业务流程和各环节的潜在分支便会变得清晰，测试用例便从"一个"自然而然地变成了"一套"。此处多提一嘴，链路思想设计用例的基础是结构清晰、圈复杂度可控制的代码风格，如果开发的时候依然尊崇"论文式"、"一刀流"，在单个方法内"长篇大论"，那链路式将是一个巨大的负担。

编写测试用例其实不是一件费劲的事，对于深耕业务代码的开发而言，编写测试用例便像是做一盘小菜，举手可为。于我而言，如今写测试用例所花费的时间甚至没有设计测试用例的时间长(凸显用例设计的重要性但也有可能是我对测试用例的设计还不够熟练)。在测试框架选型上，我更习惯于Junit+Mockito的组合，原因仅仅是熟悉与简单，且参考文档比比皆是。如果各位已经有自己习惯的框架和写法，也不必照搬本文所提及的东西，毕竟单测是为了better code，而不是自找麻烦。

但无论测试用例如何设计或是如何编写，我始终认为，在不考虑测试代码的风格和规范的前提下，衡量测试用例质量的核心指标是分支覆盖率。这也是我推荐链路思想的一大原因——从入口出发，遍历链路上各个环节的各个分支，遇到阻碍就Mock；相比于分别单测各个独立方法，单测链路所需要的入参和出参更加清晰，更是大大节省了编写测试代码所需的时间成本！计算分支覆盖率的工具有很多，例如本地的JaCoCo或是各类云化测试工具。试想，每当看到单测完美地覆盖了自己所提交的特性代码时，心里是不是放心了许多？

三   如何用链路思想设计/构造单测？

作为程序员，大家更为熟悉的链路概念应该是全链路压测。

全链路压测简单来说，就是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程，本质上也是性能测试的一种手段。... 通过这种方法，在生产环境上落地常态化稳定压测体系，实现IT系统的长期性能稳定治理。

如果将完整的业务流程视作全链路，那作为业务链上的一环，即某个后端服务，它其实也是一个微链路。这里以自上而下的开发流程为例，对于新增的功能接口，我们会习惯性地由controller开始设计，然后构建service层、dao层、api层，最后再锦上添花地加些aop。如果以链路思想，将复杂的流程拆成各个链路的各个环节，那这样的代码功能清晰，维护起来也相当方便。我非常认同 限制单个方法行数<=50 的代码门禁，对于长篇大论的代码“论文”，想必没有哪位接手的同学脸上能露出笑容的；针对这类代码，我认为clean code的优先级比补充单测用例更高，连逻辑都无法理清，即便硬着头皮写出单测用例，后续的调试和维护工作量也是不可预料的(试想，假如后面有位A同学接手了这块代码，他在“论文”中加了xx行导致ut失败了，他该如何去定位问题)。

简单画个图来强调一下我的观点。这是一张"用户买猪"的功能逻辑图。以链路思想，开发人员将整套流程拆分为相应的链路环节，涵盖了controller、service、dao、api各层；整条链路清晰明了，只要搭配完善的上下文日志，定位线上问题亦是轻而易举。

当然，基于链路思想的开发还远远不够，在补充单测用例时，我们同样也能用链路思想来构造测试用例。测试用例的要求很简单，需要覆盖controller、service等自主编写的代码(多分支场景也需要完全覆盖)，对于周边关联的系统可以采用Mock进行屏蔽，对于Dao层的SQL可以视需求决定是否Mock。秉承这个思路，我们可以对“用户买猪”图进行改造，将允许Mock的环节涂灰，从而变成我们在编写单元测试用例时所需要的“虚拟用户买猪”图。

四   快速写法实践案例

1   快速写法的核心步骤有哪些？

快速写法的入口是controller层方法，这样对于controller层存在的少量逻辑代码也能做到覆盖。

设计测试用例的输入与预期输出

设计测试用例的目的不仅仅是跑通主流程，而是要跑通全部可能的流程，即所谓的分支全覆盖，因此设计用例的输入与输出尤为重要。即便是新增分支的增量修改(例如加了一行if-else)，也需要补充相应的输入与预期输出。非常不建议根据单测运行结果修改预期结果，这说明原先的代码设计有问题。

确定链路上的全部Mock点

Mock点的判断依据是链路上该环节是否依赖第三方服务。强烈建议在设计前画出大概的功能流程图(如”用户买猪“图)，这可以大大提高确定Mock点的速度和准确性。

收集Mock点的模拟返回数据

确定Mock点后，我们就需要构造相应的模拟返回数据。Mock数据需要考虑多个因素：

a. 是否与api层对应方法的期望返回值匹配: 不能把从猪厂返回的Mock数据用牛肉替代

b. 是否与模拟输入数据匹配：用户需要1斤猪肉，不能返回5斤猪肉的数据

c. 是否与api层的所有分支匹配：部分api层会对返回值进行响应码(2xx || 3xx || 4xx)校验，这类场景便需要构造不同响应码的Mock数据

2【开发篇】真实用户买猪

该项目基于PandoraBoot构建，手动升级SpringBoot版本至2.5.1，使用Mybatis-plus组件简化Dao层开发过程。下面选取了上文图中所涉及的重要方法进行展示，仅实现了简单的业务流程，系统框架和工程结构可以参考代码仓。

来源：阿里技术