有赞单元测试实践

文 | 国庆  on 商品中心

一、概述

单元测试是指对软件中的最小可测试单元进行检查和验证。单元在质量保证中是非常重要的环节，根据测试金字塔原理，越往上层的测试，所需的测试投入比例越大，效果也越差，而单元测试的成本要小的多，也更容易发现问题。

1.1 有赞单元测试1.0架构

以有赞中台某应用为例，应用部署是微服务架构，对外提供dubbo服务，当前的单元测试，采用了分层测试框架，根据代码的分层，分为 Service 层测试，Biz 层测试，外部服务访问层测试，DAO 测试，Redis 访问层测试，每一层均使用 mock 框架屏蔽下层的具体实现。

1.2 单元测试的过程

单元测试的编写，主要包含以下几个阶段：

1. 数据准备：在编写测试用例前，需要依赖到一些数据，数据来源一般是数据库，而构造数据，又不能依赖 DAO 层的代码，需要使用原生jdbc 去插入数据，测试代码编写效率低。

2. 构造参数及打桩（stub）：调用方法需要传递入参，有时候一个入参十几个参数需要 set，set 方法写完，代码已经写了十来行了。

3. 执行测试：这一步比较简单，直接调用被测方法即可。

4. 结果验证：这里除了验证被测方法的返回值外，还需要验证插入到数据库中的数据是否正确，某外部方法被调用过n次或未调用过。

5. 必要的清理：对打桩进行清理，对数据库脏数据进行清理。

二、 痛点

2.1 重构代码需要改写大量单元测试用例

对外的 Service 接口在不变的情况下，对内部实现进行重构，这时候头痛的问题来了，大量的 Service 层单元测试,biz 层单元测试都要重写；有时候 Service 调用 biz 层接口时，参数传错了，而由于开发人员编写单元测试时不规范，参数匹配使用了  anyxxx()，导致参数传错的 bug 未被发现。

2.2 测试库数据随意修改导致的单元测试不稳定

DAO 层单元测试直连测试库，由于测试库的数据可以被任意修改，从而导致测试依赖的数据被更改，单元测试不通过，另外开发在编写单元测试时，没有清理意识，导致测试库大量垃圾数据。

2.3 单元测试结果校验缺失

例如一个 SaveItem() 接口，执行完成后除了要验证执行成功以外，还应该验证落库数据的正确性，而编写这部分测试代码需要大量的使用原生 jdbc 接口查询 sql，并逐字段验证正确性，代码编写效率低下。

三、几个常用的测试框架的简介

3.1 数据层单元测试框架 DbUnit

可以优雅的构造 DB 层的初始化数据，例如：

其中 employee 是要构造数据的表名，后面的键值对是列名及对应的值，需要注意的是，第一行必须包含完整的字段名，否则加载的数据中全部会缺失某些字段。

3.2 嵌入式的内存数据库H2

非常适合在测试程序中使用，程序关闭时自动清理数据，H2 数据库的表结构初始化是通过 jdbc:initialize-database 标签实现的，单元测试中使用 H2 数据库非常简单，仅需修改 jdbc 连接即可。 引入依赖：

数据源连接：

schema 初始化:

3.3 Spring 小扩展 springockito

它简化了在集成测试的相关上下文XML文件中创建 mockito mocks 的方法。

3.4 spring 官方测试框架 spring-test

目前主流的开发框架都在使用 spring 框架管理 bean，在测试代码中，我们通用期望能够使用 spring 框架，spring-test 框架帮助我们解决 bean 的注入问题。

"/test-context.xml" 指定了测试类运行需要加载的 spring 配置文件路径， SpringockitoContextLoader 指定了加载配置的类，这两个一起用可以支持在使用 spring xml 配置的同时可以将 mockito 生成的 mock 对象 bean 注入 spring 上下文中。

3.5 支持静态方法 mock 的 mock 框架 powermock

支持静态方法 mock，同时兼容 mockito，powermock 示例：

四、有赞基于 springtest+ut+powermock 的测试框架

有赞单元测试框架，数据库层使用 h2 数据库代替测试库，隔离单元测试数据与测试库数据，在单元测试结束后自动清理数据，避免污染测试库数据及被测试库数据影响，基于 DbUnit 可以通过 xml 构造 DB 层初始化数据，实现测试代码与测试数据分离，依赖 spring jdbc 的初始化脚本初始化 h2 数据库的表结构。

4.1 数据准备

以下是单元测试代码示例，enablePrepare 声明需要准备数据，prepareDateConfig 声明数据准备的文件路径，prepareDateType 是数据准备的类型，xml -> DB，当然也支持更多的文件类型，如 csv，xls。

4.2 桩代码相关框架

PowerMock 集成 Spring TestContext 框架

4.3 结果验证

结果验证，包括两部分，一个是被测函数的返回值，这个需要编写者自行验证，另一个是写入数据库的值，这部分是通过在方法上添加注解，告诉单元测试框架要验证的语句，执行验证语句并与期望值比较。
单元测试方法示例：

saveUserCheck.json 文件内容示例

4.4 以下是单元测试基类的示例代码

五、总结

第二部分提到的几个痛点，通过我们的 zantest 测试组件，我们完美的解决这几个问题，通过注解方式，实现了配置数据与测试代码的分离，简化测试代码编写，隔离测试环境数据库，并编写了一套测试示例进行推广。

5.1 关于内部重构的痛点，我们基于有赞单元测试框架解决了这个问题

在单元测试 1.0 版本时，我们分别对 Service，innerBeanA，innerBeanB，UserDAO 写单元测试，当 Service 层输入输出不变，内部重构时，这几个类的单元测试都要重构，而在单元测试 2.0 版本时，由于被测函数只有 Service，通过桩代码控制 Service 对 innerBeanA，innerBeanB，UserDAO 的调用，从而覆盖 inner 层和 DAO 层，重构时只需要改写 Service 层代码即可。

5.2 测试库数据被随意修改

数据准备不再依赖测试库，而是通过文件构造测试数据，例如上文的 xml 格式，为方便测试数据的构造，同时也支持更多的数据格式，例如 csv，可以方便的将线上数据导出作为测试用例。

5.3 单元测试结果校验

一方面开发仍然需要自行校验函数的返回值，校验 mock 函数是否被执行，另一方面对数据库数据更改的验证可以直接通过注解声明校验的 sql 文件路径即可。

相关链接

DbUnit： http://dbunit.sourceforge.net/howto.html

H2： http://www.h2database.com/html/quickstart.html

springockito： https://github.com/springockito/springockito

spring-test： https://docs.spring.io/spring/docs/current/spring-framework-reference/testing.html#testing

powermock： https://github.com/powermock/powermock

拓展阅读

1. 有赞业务对账平台的探索与实践

2. 赞订单导出的配置化实践

3. 有赞订单管理的三生三世与“十面埋伏”

4. 有赞订单搜索AKF架构演进之路

5. 有赞亿级订单同步的探索与实践

-The End-

Vol.185

有赞技术团队

为 442 万商家，150 个行业，330 亿电商交易额

提供技术支持

微商城｜零售｜美业 | 教育

微信公众号：有赞coder    微博：@有赞技术

技术博客：tech.youzan.com

The bigger the dream, 

the more important the team.