在微服务架构下高覆盖率的单元测试是保障代码质量的第一道也是最重要的关口，应该持之以恒。
背景
单元测试为代码质量保驾护航，是提高业务质量的最直接手段，实践证明，非常多的缺陷完全可以通过单元测试来发现，测试金字塔提出者 Martin Fowler 强调如果一个高层测试失败了，不仅仅表明功能代码中存在 bug，还意味着单元测试的欠缺。因此，无论何时修复失败的端到端测试，都应该同时添加相应的单元测试。而越早发现发现 Bug，造成的浪费就会越小，单元测试本身就能够提供了快速反馈的机制。另外，单元测试是一个优秀的开发工程师必备技能之一，优秀的单元测试是业务快速投产的加速器。
单元测试的意义
虽然对于 100% 的单元测试覆盖率我们持有保留态度，但在一个微服务架构基础设施还不完善、开发人员能力参差不齐、DDD（领域驱动设计）能力不足以应对复杂业务的情况下，单元测试是性价比最高的实践。单元测试可以充当一个设计工具，它有助于开发人员去思考代码结构的设计，让代码更加有利于测试，满足架构的可测性设计要求。
单元测试的意义包括如下内容：
尽早发现缺陷，降低开发投入成本
85% 的缺陷是代码阶段产生的，单元测试阶段可以发现绝大部分软件缺陷。同时软件产品的缺陷发现的越早往往会大大的降低其开发的投入成本，其缺陷的发现时间与修复缺陷的成本如下图中红色曲线。红色曲线表明随着软件开发的进行，漏洞越早发现，其修复的成本越低，并且其修复成本与开发进度的上升趋势越在后期越接近于指数上升。
放心重构
无论是对单体项目还是单体项目向微服务架构迁移，代码都在不断的在变化和重构，通过单元测试，开发可以放心的修改重构代码，减少改代码时心理负担，提高重构的成功率。
改进设计
越是良好设计的代码，越容易编写单元测试，多个小的方法的单测一般比大方法（成百上千行代码）的单测代码要简单、要稳定，一个依赖接口的类一般比依赖具体实现的类容易测试，所以在编写单测的过程中，如果发现单测代码非常难写，一般表明被测试的代码包含了太多的依赖或职责，需要反思代码的合理性，进而推进代码设计的优化，形成正向循环。选择测试驱动开发（TDD）的模式进行项目开发，以单元测试引导项目实现。这种模式下单元测试先行，根据单元测试代码开发功能代码，进而非常精准的实现业务需求，减少返工和缺陷率，可提高项目质量和效率。
“
单元测试的常见误解
单元测试浪费了太多的时间
虽然不进行单元测试可以更快的交付到后续测试阶段，但是在后续集成测试阶段、系统测试阶段会发现更多的缺陷甚至软件无法运行的致命缺陷，这些缺陷修复的时间远超过单元测试的时间。另外没有单元测试的代码后期软件进行重构或者改进时花费的时间也比有单元测试的所花费的时间要多很多。所以说完整计划下的单元测试是对时间的更高效的利用。已经有接口集成测试、系统功能测试进行质量保证了，集成测试阶段对接口进行全面测试就可以达到单元测试的要求，没必要做重复工作在进行单元测试。
接口测试和功能测试无法覆盖所有的代码，这样如果缺陷存在则将被遗漏，并且 Bug 将被带到生产上去。一旦用户使用过程中触发了这些没有测试的代码就会带来严重的经济后果。跑通一个业务主流程等价于做过单元测试
目前有很多开发人员认为，开发完代码之后，写个 main 方法，从入口调完所有的模块，最后验证下返回结果，就认为做过单元测试了，这种想法是及其错误的，这充其量算一种不全面的冒烟测试，是对单元测试概念的错误认知。
微服务架构下如何开展单元测试
下面将从单元测试所处的阶段、单元测试用例设计规范、单元测试实现几个维度分别介绍如何在微服务架构下开展单元测试。首先看下单元测试所处的阶段，下图为非 TDD 模式下单元测试所处的阶段
由图可见单元测试处在特性分支开发完成之后，具体的描述如下：
1. 开发人员从 Master 分支拉取特性分支作为开发分支；2. 开发完特性分支后、代码构建、单元测试、静态代码扫描；3. 通过后合并到 Master 分支，用于投产。下面看下什么样的单元测试用例是优秀的用例，是即满足运行速度又满足高覆盖率的用例。随行付定制了单元测试规范，下面节选了强制要求的部分规范。优秀的单元测试用例要符合以下用例设计规范的要求。
1. 必须遵守 AIR 原则
【说明】单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。A：Automatic（自动化）I：Independent（独立性）R：Repeatable（可重复）2. 单元测试应该是全自动执行的，并且非交互式的
【说明】测试框架通常是定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。3. 保持单元测试的独立性
【说明】为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。反例：method2 需要依赖 method1 的执行，将执行结果做为 method2 的输入 4. 单元测试是可以重复执行的，不能受到外界环境的影响
【说明】单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。5. 对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别
【说明】只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域 6. 核心业务、核心应用、核心模块的增量代码确保单元测试通过
【说明】新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正 7. 单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下
【说明】源码构建时会跳过此目录，而单元测试框架默认是扫描此目录随行付在推行单元测试落地过程中采用循序渐进的方式，逐步增加单元测试用例达到单元测试规范中规定的覆盖率要求。需要说明的是我们不是追求覆盖率这个数字指标，那样就舍本求末了，我们是通过覆盖率这个可以量化的指标实现提高代码质量的这个根本目的。
第一阶段：单元测试覆盖率要求至少 25%
第二阶段：单元测试覆盖率要求至少 60%
第三阶段：单元测试覆盖率要求至少 80%
随行付单元测试覆盖率统计同样采用 SonarQube 平台结合 Jenkins 工具，Jacoco 单元测试覆盖率工具完成，这个同上篇介绍的静态代码扫描流程是一脉相承的。同时要求开发人员本地的 IDE 工具中安装 Jacoco 覆盖率插件，当本地开发完单元测试用例并构建后，即可看到覆盖率信息，进而可以快速补充用例，达到覆盖率要求。以 Eclipse 为例，当开发完单元测试代码后，按照如下操作即可查看覆盖率信息。
1. 选择需要统计的 java 测试代码或者包;
2. 右键，Coverage as->Junit
3. 覆盖率结果会自动在 Coverage 视图中展示出来;
4. 在 Java 编辑器中用不同的颜色标识代码的覆盖情况。
【说明】绿色 —- 全覆盖
红色 —- 未覆盖
黄色 —- 部分覆盖
下面介绍下在微服务下应该如何进行单元测试。为了有效的进行单元测试，需要遵循一定的方法，通常采用路径覆盖法设计单元测试用例。所谓路径覆盖法就是选取足够多的测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）。具体设计过程参见如下步骤：
1. 画出程序控制流程图
2. 计算圈复杂度
3. 找出所有程序基本路径
4. 根据路径设计测试数据
以下图代码为例说明路径覆盖法的设计单元测试的过程 1. 首先根据代码画出其对应的流程图如下，图中数字代表行号。当条件语句中包含多个条件时应予以拆分，如第 13 行，拆分为 13.1 和 13.2；对于没有分支和循环的语句可忽略，如第 16 行。有了流程图后，我们可以根据它计算出圈复杂度，这个可以作为测试用例数的上限，圈复杂度计算公式如下：
V（G）= E – N + 2，E 是流图中边的数量，N 是流图中结点的数量。V（G）= P + 1，P 是流图 G 中判定结点的数量。
两个公式用哪个都行，最后的结果应该是一样的。这里我们用第二个公式，V（G）= 3 + 1 = 4，也就是我们只需要设计 4 条用例即可覆盖所有路径
接下来就是找出所有基本路径，基本路径是从程序的开始结点到结束可以选择任何的路径遍历，但是每条路径至少应该包含一条已定义路径不曾用到的边，所有的基本路径如下
A
B C
B D E F
B D E G E F
得到了所有的基本路径，剩下的简单了，只需要按照路径设计出对应的入参数据即可
案例 1：a = 0, b = 1, 期望值 -1
案例 2：a = 1, b = 0, 期望值 -1
案例 3: a = 4, b = 2, 期望值 2
案例 4：a = 8, b = 12, 期望值 4
除此之外，单元测试用例设计还需要考虑以下场景
边界值
业务边界
溢出边界
字符串、数组、集合等的边界
异常场景
业务异常
输入异常（如参数不合法）
正常场景
单个模块的用例设计都可以按照路径覆盖法达到语句覆盖和分支覆盖，但是对于有依赖关系的模块
在微服务架构下，每个模块之间会存在依赖的情况，为了保持单元测试的独立性原则，在不依赖于外部条件的情况下制造各种输入数据，需要借助 Mock 技术，其本质是用一个模拟的对象代替真实的对象（例如一个类、模块、函数或者微服务）。模拟对象的行为特征和真实对象非常相似，采用相同的调用逻辑，返回内容按照之前预定义的内容返回，提供返回数据。Mock 技术的原理可以用如下案例进行解释。
当要进行单元测试时，需要给 A 注入 B 和 C, 但是 C 又依赖 D，D 又依赖 E。这就导致了，A 的单元测试不满足独立性原则。但使用了 Mock 来进行模拟对象后，就可以把这种依赖解耦，只关心 A 本身的测试，它所依赖的 B 和 C，全部使用 Mock 出来的对象，并且给 MockB 和 MockC 指定一个明确的行为。
在单元测试工具的选择方面，随行付单元测试借助 Junit 工具和 Mockito 工具进行单元测试，微服务架构下不管是 spring boot 还是 spring cloud，通常使用 @SpringBootTest 注解进行单元测试。一个单元测试的实现步骤主要包括 4 步：
1. 设置测试数据
2.Mock 依赖的系统并给定预期值，如果没有依赖这步可以省略
3. 在测试中调用方法
4. 断言返回的结果是否符合预期
下面以一个非常简单的例子介绍在微服务架构下如何对 spring boot 中的 controller 层和 service 层进行单元测试。
调用逻辑简化版如图所示，Controller 调用 ServiceA，ServiceA 依赖 ServiceB。
被依赖 ServiceB 的代码如下
package cn.vbill.quality.service; import org.springframework…Service;
@Service public class ServiceB {
public boolean serve(int param) {
return param % 2 == 0;
}
} 被测 ServiceA 的代码如下
package cn.vbill.quality.service;import org.springframework.beans…Autowired;import org.springframework.stereotype.Service;
@Servicepublic class ServiceA {@Autowired private ServiceB srvB;
public String doSomething(int param) {
if (srvB.serve(param)) {
return “even”;
}
return “obb”;
}}ServiceA 和 ServiceB 的逻辑非常简单，现在测试 ServiceA，步骤如下：
首先：在 gradle 中增加测试需要的依赖包
// 可根据实际情况添加版本号 testCompile(“org.springframework.boot:spring-boot-starter-test”) 其次：在 src/test/java 下面创建测试类，采用 @SpringBootTest 注解和 Mockito 技术对 ServiceB 进行测试和 Mock, 更多 Mockito 的使用可以参考其他文章，这里不过多介绍。代码如下：
最后，使用覆盖率工具查看单元测试覆盖率，如下图所示，实现了 100% 覆盖。
ServiceB 没有任何依赖，因此对它测试就按照常规的 Junit 测试即可，这里不过多介绍。下面介绍 Controller 层的单元测试，整体上看 Controller 层的测试和 Service 层大致相同，只不过是我们不去直接调用 Controller 的方法，而是通过 MockMvc 模拟 HTTP 请求。从逻辑图上看 Controller 是直接调用 ServiceA，因此需要使用 Mockito 模拟 ServiceA。
被测 Controller 代码逻辑如下：
测试类如下
最后，通过覆盖率工具查看单元测试覆盖率为 100%，做到了全覆盖。
以上是如何在微服务架构下进行单元测试进行了详细的介绍，在微服务架构下高覆盖率的单元测试是保障代码质量的第一道也是最重要的关口，应该持之以恒。
总结
本篇分别从微服务架构下开展单元测试的意义、对单元测试的常见误解以及如何开展单元测试三个方面进行介绍，单元测试是一项成本低、收益高的实践，要利用好这把利剑，打好代码质量基础，为后续的质量保证过程添砖加瓦。
作者介绍
王田，随行付架构部测试架构师。负责测试方法论布道、自动化测试工具研究与推广。