优秀单元测试实战（三）

前言

上篇主要讲解了如何编写规范的单元测试，本篇将继续讲解如何去编写可靠的单元测试，以及相关实战范例的内容。

4

编写可靠的单元测试

怎样的单元测试才是可靠的呢？

所谓可靠性是指单元测试本身是正确的，设计出的覆盖各种正常和异常场景的测试用例，在任何预期或非预期的情况下都能正确运行。只有保证单元测试的可靠性，才能让开发人员信任该单元测试。

从哪些角度的思考与设计，可以让单元测试代码变得可信赖和可靠呢?

1、保持你的测试是幂等的

单个测试方法测试多次，结果都应该是一样的。我们应编写唯一确定性结果的单元测试。

2、适时删除或修改单元测试

若源码方法被修改或重构了，应根据实际情况合理地删除或修改单元测试。或者确定是测试代码缺陷，而不是被测试代码缺陷时，也需要立刻修改相关单元测试代码，以保证单元测试始终是最新的、正确的。

3、不应依赖运行环境的数据

对于必须的初始化数据，可使用Mock组装。不应通过SQL脚本初始化数据再删除(防止删除时发生异常数据库依然会有脏数据)，或者依赖本地资源文件、数据，否则单元测试在其它环境将无法运行。

4、不应依赖数据库等不可控组件

如果代码中依赖了数据库、Redis集群等不可控的组件，则这些测试代码在其它运行环境，可能无法运行。对于这些复杂的模块或类，需要通过Mock的方式，将这些不可控的部分变成可控，确保单元测试在何时何地都能够成功运行。

不依赖数据库：

说明：通过修改src/test/resources下的Spring测试配置文件，创建所需注入的模拟Jdbc模板等工具类。在编写单元测试时，如果有用到jdbc模板等工具类的，需要自行设置Mock触发，传入参数返回相应的结果，最后使用Mockito.verify对Mock进行预期验证。

不依赖Redis集群：

说明：通过修改src/test/resources下的Redis测试配置文件，创建所需注入的模拟Redis模板等工具类。在编写单元测试时，如果有用到Redis模板等工具类的，需要自行设置Mock触发，传入参数返回相应的结果，最后对预期结果进行验证。

5、应用Mock工具后应还原

使用了Mock、Spy的单元测试类，在结束后都重置回原接口实现(因为测试一般在同一应用上下文，mock未还原，可能会对其它单元测试类有影响，比如同一业务的query、writter接口)。可使用WhiteBox、ReflectionTestUtils、 Mock 注解等工具。

Mock注解、ReflectionTestUtils应用：

6、应对Mock接口验证预期执行

测试调用了Mock接口的方法，应验证Mock方法是否按预期执行。可使用Mockito.verify进行验证。

7、拒绝滥用Mock

滥用Mock会导致一些基本功能无法得到验证，Mock更适用一些已经被验证的方法、远程接口调用、发送邮件、网络通讯等场景的模拟。另RPC调用建议使用Mock，非RPC调用建议使用Spy(spy会真实调用执行，并返回预期设置结果)。

结语

本篇主要讲解了如何编写可靠的单元测试，讲解了如何应用Mock不依赖于应用环境，保证单元测试的稳定性。使用Mock有一定的编程量和复杂度，也可通过搭建一个稳定的测试环境，所有数据从这个环境中获取，也可保证单元测试结果的稳定。下篇将详解如何编写高覆盖率的单元测试，敬请继续关注。

—END—