基于链路思想的 SpringBoot 单元测试快速写法

引言：

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

一 为什么要写单元测试？

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

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

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

二 为什么推荐链路思想？

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

1. 应该如何设计测试用例？
2. 应该如何编写测试用例？
3. 测试用例的质量该如何判定？

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

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

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

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

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

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

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

如果将完整的业务流程视作全链路，那作为业务链上的一环，即某个后端服务，它其实也是一个微链路。这里以自上而下的开发流程为例，对于新增的功能接口，我们会习惯性地由controller开始设计，然后构建service层、dao层、api层，最后再锦上添花地加些aop。如果以链路思想&#x