本文1-2章是单测的介绍,如果需要直接看整合教程,直接跳至第3章看干货;
在复杂系统的开发中,我们经常需要做单元测试。但又由于单元测试没有形成标准,而经常遇到这样的问题:
而不做单元测试,将又会带来:
针对以上问题,本文将介绍基于集成Mockito + PowerMock + H2 + EmbededRedis 的单元测试实践方案,整套单元测试环境将完全脱离Spring框架进行,使得功能验证更加纯粹简单。
Java的单元测试就是测试各个独立方法的功能是否符合预期以及边界值限定的情况。单元测试不只是为了验证你当前写的代码是否存在问题,更为重要的是他可以很大程度保障日后因业务变更,开发成员变更,修复BUG或者重构引起的代码变更而导致(或新增)的风险
A:Automatic(自动化)
即单元测试具备可自动化运行的能力,测试用例通常是被定期执行的,执行过程必须完全自动化才有意义。如: 集成CI能力,在每一次commit过后,在pipeline中进行各项单元测试集合的自动化运行(不准使用 System.out
来进行人肉验证,必须使用 assert
来验证),并给出自动化单元测试运行的结果(pass/fail);
I:Independent(独立性)
为了保证单元测试稳定可靠且便于维护,单元测试用例之间决不能互相调用,也不能依赖执行的先后次序;单元测试也不依赖任何外部的系统或组件(如外部系统、外部Mysql、外部密钥等),而是自身具备独立可测试的能力,方便于任何第三方拿到单测之后都可以直接运行并验证功能;
R:Repeatable(可重复)
单元测试应该是可重复的,每次运行的运行都应该不应该受到外部系统或者外部数据影响。一旦数据和可用性问题,结果就会像幽灵一样时好时坏;也不能因为这次创建了数据,下次就因为主键约束不能再创建。
单元测试实际上建议单独一个项目模块(实在不行则在项目顶级依赖如start项目下做),否则每个模块都要重新做一次单独单测环境;
简单来说,本章节将会脱离Spring环境,转而使用完全的Mockito环境进行单元测试。
即:使用内存数据库H2作为数据源,使用Mockito对目标对象进行打桩与验证、使用PowerMock对静态方法、私有方法进行模拟与打桩。
有什么好处吗? 完全脱离Spring环境之后,使得单元测试更加纯粹,项目启动速度特别快;
有什么坏处吗?Spring的特性就无法使用了,比如Autowire一个List和Autowire一个Map等;Mybatis等数据源的注入需要手工注入了;
具体版本以最新为准
用于脱离Sping环境进行单元测试,对数据进行打桩,对外部数据源、外部服务进行模拟
org.mockito
mockito-core
3.9.0
test
用于mock静态方法、私有方法等,是mockito的增强使用
org.powermock
powermock-module-junit4
2.0.2
test
org.powermock
powermock-api-mockito2
2.0.2
test
用于单侧时启动一个本地的内存数据库进行数据源准备与数据库数据的初始化
com.h2database
h2
test
若单测时需要使用到redis的能力,可以使用embededRedis
com.github.kstyrc
embeded-redis
0.6
实际上,实际上,可以使用testcontainer拉取一个镜像并运行一个临时实例来代替(但个人感觉这样有点慢)
完成了如上的依赖引入之后,我们便有了一套真正意义上的单元测试工具了。
本节将阐明如何脱离Spring进行单元测试前的准备:
因为单元测试脱离了Spring,因此我们要引入新的mybatis.conf,因此我们在test目录下,添加一个适用于H2数据库连接的mabatis-test.conf
先增加一个可以读取本地文件的工具ReadFileUtil,专门用于读取ddl.sql与预置sql数据。(这里偷懒,直接用了Spring的StreamUtils和Fastjson的序列化能力)
package com.teamer.teapot.util;
import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.TypeReference;
import org.springframework.core.io.ClassPathResource;
import org.springframework.util.StreamUtils;
import java.io.IOException;
import java.nio.charset.Charset;
/**
* @author tanzj
* @date 2022/9/17
*/
public class ReadFileUtil {
/**
* 用于从指定路径中读取资源,并转换为特定对象
*
* @param path 路径
* @param typeReference 类型
* @param 类型
* @return 指定类型的对象
*/
public static T readJsonFromResource(String path, TypeReference typeReference) {
try {
String jsonString = StreamUtils.copyToString(
new ClassPathResource(path).getInputStream(), Charset.defaultCharset()
);
return JSON.parseObject(jsonString, typeReference);
} catch (IOException e) {
e.printStackTrace();
return null;
}
}
public static String readStringFromResource(String fileName) throws IOException {
return StreamUtils.copyToString(new ClassPathResource(fileName).getInputStream(), Charset.defaultCharset());
}
}
编写一个H2DbSupportFactory工具,此工具用于单元测试时Mapper对象的导入
package com.teamer.teapot.util;
import org.apache.ibatis.io.Resources;
import org.apache.ibatis.session.SqlSession;
import org.apache.ibatis.session.SqlSessionFactory;
import org.apache.ibatis.session.SqlSessionFactoryBuilder;
import org.testcontainers.shaded.org.apache.commons.lang.StringUtils;
import java.io.IOException;
import java.io.Reader;
import java.sql.SQLException;
import java.util.Arrays;
public class H2DbSupportFactory {
public static SqlSessionFactory sqlSessionFactory;
public static SqlSession sqlSession;
public boolean dataInited = false;
static {
//测试用的mybatis-test文件
try(Reader reader = Resources.getResourceAsReader("mybatis-test.xml")) {
sqlSessionFactory = new SqlSessionFactoryBuilder().build(reader);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static H2DbSupportFactory getInstance(String[] ddlPath, String[] initDataPath) throws IOException, SQLException {
//获取数据库建表语句脚本
StringBuilder ddlSqlStrBuilder = new StringBuilder();
for (String eachDdlSqlPath: ddlPath) {
String currentSql = ReadFileUtil.readStringFromResource(eachDdlSqlPath);
ddlSqlStrBuilder.append(currentSql);
if (!currentSql.endsWith(";")) {
ddlSqlStrBuilder.append(";");
}
}
//获取初始化数据
StringBuilder initDataPathStringBuilder = new StringBuilder();
if (!Arrays.stream(initDataPath).allMatch(StringUtils::isEmpty)) {
for (String eachInitDataPath : initDataPath) {
String currentSql = ReadFileUtil.readStringFromResource(eachInitDataPath);
initDataPathStringBuilder.append(currentSql);
if (!currentSql.endsWith(";")) {
initDataPathStringBuilder.append(";");
}
}
}
String ddlSql = ddlSqlStrBuilder.toString();
String initDataSql = initDataPathStringBuilder.toString();
H2DbSupportFactory factory = new H2DbSupportFactory();
factory.setSqlSession(getSqlSessionFactory().openSession());
if (factory.getSqlSession() == null) {
sqlSession = getSqlSessionFactory().openSession();
}
if (StringUtils.isNotBlank(ddlSql)) {
//h2每次只能创建一张表
String[] ddlSqlList = ddlSql.split(";;");
for (String eachDdlSql : ddlSqlList) {
sqlSession.getConnection().createStatement().execute(eachDdlSql);
}
}
if (StringUtils.isNotBlank(initDataSql) || !factory.dataInited) {
sqlSession.getConnection().createStatement().execute(initDataSql);
factory.dataInited = true;
}
sqlSession.commit();;
return factory;
}
public SqlSession getSqlSession() {
return sqlSession;
}
public boolean isDataInited() {
return dataInited;
}
public H2DbSupportFactory setDataInited(boolean dataInited) {
this.dataInited = dataInited;
return this;
}
}
编写单元测试基类,让所有基于此方案的单元测试直接继承这个基类,从而省去每次编写单测的前置工作。
@RunWith(PowerMockRunner.class)
public abstract class BaseMockitoTest {
protected static H2DbSupportFactory h2DbSupportFactory;
/**
* 用于为target注入对象,目前用于Mapper层的手工注入
* @param target 目标业务对象
* @param field 字段
* @param dependency 依赖的对象
* @throws NoSuchFieldException e
* @throws IllegalAccessException e
*/
public void setter(Object target, String field, Object dependency) throws NoSuchFieldException, IllegalAccessException {
Field targetField = target.getClass().getField(field);
if (!targetField.isAccessible()) {
targetField.setAccessible(true);
}
targetField.set(target, dependency);
}
/**
* 子类集成时,需要在方法增加@Before注解,用于提前打桩
* @see org.junit.Before
* @throws Exception e
*/
public abstract void before() throws Exception;
/**
* 子类集成时,需要在方法增加@BeforeClass注解,用于提前静态类初始化能力的集成
* @see org.junit.BeforeClass
*/
public static void init() {
};
}
若是单测需要依赖redis的能力,则需要提前配置好redis的基础配置。案例使用jedis作为redis-client,若使用其他工具,配置也大同小异。
/**
* @author tanzj
* @date 2022/9/19
*/
public class EmbeddedRedisHolder {
private static RedisServer redisServer;
private static Jedis jedis;
private static JedisPool jedisPool;
/**
* 启动器,需要在@BeforeClass中调用初始化
*/
public static void startUp() {
redisServer = RedisServer.builder()
.port(63792)
.setting("maxmemory 64m")
.build();
redisServer.start();
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(200);
jedisPoolConfig.setMaxWaitMillis(2000);
jedisPoolConfig.setMaxIdle(8);
jedisPoolConfig.setMinIdle(0);
jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 63792, 10000);
}
/**
* 进程销毁,需要在@AfterClass中调用销毁
*/
public static void end() {
redisServer.stop();
}
public static Jedis getJedis() {
if (jedis != null) {
return jedis;
}
if (jedisPool == null) {
initJedisPool();
}
jedis = jedisPool.getResource();
return jedis;
}
private static JedisPool initJedisPool() {
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(200);
jedisPoolConfig.setMaxWaitMillis(2000);
jedisPoolConfig.setMaxIdle(8);
jedisPoolConfig.setMinIdle(0);
jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 63792, 10000);
return jedisPool;
}
public static JedisPool getJedisPool() {
return jedisPool;
}
}
开始编写业务单元测试。我们先模拟一个新增订单的一个业务逻辑。
我们需要对Controller层是简单的路由转发,我们在开发中只需要对OrderService的createOrder方法进行业务的单元测试,具体的代码层级结构如下:
- OrdereController:业务入口
- OrderService:是业务逻辑层,主要提供了创建单据与查询单据详情的方法,Service层聚合了OrderInfoManager(单据通用逻辑层)与OrderItemDetailManager(单据明细通用逻辑层)
- OrderInfoManager/OrderItemDetailManager:通用逻辑层,包装了DAO与单据特性的通用能力
- DAO层:数据访问层
- 各模块的注入使用了@Autowire注入
根据单元测试规范,我们需要在test目录下新建一个与被测类相同路径的单元测试方法,并且以Test结尾,如我们需要测试的方法是:com.teamer.teapot.order.service.impl.OrderServiceImpl,那么此时我们就需要在test目录下新建com.teamer.teapot.order.service.OrderServiceImplTest的单元测试方法:
/**
* @author tanzj
* @date 2022/9/21
*/
public class OrderServiceTest extends BaseMockitoTest {
/**
* 子类集成时,需要在方法增加@Before注解,用于提前打桩
*
* @throws Exception e
* @see Before
*/
@Before
@Override
public void before() throws Exception {
}
}
如3.3的大图所示,我们知道OrderService是依赖了OrderInfoManager 与 OrderItemDetailManager 的两个bean,因此在单元测试中,我们需要使用InjectMocks将这两个依赖也定义出来。
@InjectMocks可以将所有使用@InjectMocks, @Spy,@Mock 修饰的字段,全部注入到当前修饰的字段中,有点类似Spring的注入。
public class OrderServiceTest extends BaseMockitoTest {
/**
*
使用InjectMocks定义一个对象时,这个对象会自动注入所有使用@InjectMocks与@Spy,@Mock 注解的字段
*
这里使用spy构造是因为我们确实要走他的创建方法
*/
@InjectMocks
private OrderService orderService = Mockito.spy(new OrderServiceImpl());
/**
* orderService 依赖了orderInfoManager,我们这里同样要注入MockOrderInfoManager
*/
@InjectMocks
private OrderInfoManager orderInfoManager = Mockito.spy(new OrderInfoManagerImpl());
/**
* 同理
*/
@InjectMocks
private OrderItemDetailManager orderItemDetailManager = Mockito.spy(new OrderItemDetailManagerImpl());
/**
* 子类集成时,需要在方法增加@Before注解,用于提前打桩
*
* @throws Exception e
* @see Before
*/
@Before
@Override
public void before() throws Exception {
}
}
此时如果我们任意启动一个单元测试,通过debug,便会发现所有的对象都被注入成功了
Mockito不推荐我们对value对象进行注入模拟,因此针对于DAO对象,我们直接使用打桩返回的形式进行测试,在单元测试类中注入两个DAO
在before方法加上@Before注解,并对这两个Bean进行提前打桩。
对mock的对象,打桩格式是:
when(mockBean.doSomething(any())).thenReturn(requireObject);
对spy对象,打桩格式是
doReturn(requireObject).when(spyBean).doSomething(any())
注意:这里的Mock更可以用在第三方系统或者接口、服务尚未准备好的情况下,我们去提前在单元测试中模拟返回(不仅如此,根据AIR原则,我们也必须对第三方接口和服务进行Mock)
基于3.3.3的前提下,我们可以完成大部分的单元测试。但在很多时候,只有真正走到了SQL层面,才能验证你的sql是否准确,字段约束是否齐全,这个时候就需要引入H2内存数据库进行单元测试了。
因此我们在准备好3.2.3的DB连接与初始化工具之后,便可以准备db的初始化了。
我们为单元测试增加init()方法,并为其加上@BeforeClass注解,提前准备好对应表的ddl语句和事先准备好的的数据初始化sql脚本
在mybatis-test.conf中注册这两个DAO
然后在before()方法中,对DAO进行初始化(注意,如果使用这种方法,需要取消3.3.3中,对dao的@Mock注解)
这样便完成了DAO对象的注入。
此时,我们需要调用基类的setter()方法,利用反射对业务对象中的DAO进行赋值(这里笔者没有找到更好的办法对dao进行注入,如果有更好的办法请一定不吝赐教)
完成此步骤之后,单元测试中便完成了数据源与DAO的注入配置。值得注意的是,H2的语法与Mysql有些许不同,比如H2便不支持json操作。若设计到json的字段,请在ddl脚本将其设置为text字段。
若被测方法使用到了redis的特性,我们可以使用3.2.5中提前准备好的embededRedis启动器进行redis测试。
我们依然在beforeClass中先启动redis
新建一个方法:destroy,并为此方法新增注解@AfterClass,在此方法中调用redisEnd
此时便完成了embededRedis的启动了。而后在业务单元测试方法中,对jedisPool进行注入
这样在你使用到redis的位置,用此jedisPool来拉取jedisClient时便可以拿到我们预先配置的bean了
而后,我们针对OrderService每一个业务方法,都进行单元测试,并基于单元测试的标准对其边界值进行测试。并对其结果进行断言(不对结果进行断言的单元测试都是耍流氓)
如:
实际上,参考Mockito官方的写法,我们建议单元测试的方法命名为:
test + ${method} + "_success"
test + ${method} + "${用下划线隔开的场景}"
因为这样,在跑单元测试的边界值测试时,才更能一幕了然的看到所有被测试的场景