基于mockito做有效的单元测试
概述
本文讲解的主要是有效和单元的思想,并不是说如何编写单元测试,用于改善和提高开发效率、编码风格、编码可读性和单测效率,不盲目追求覆盖率。
背景
-
现在很多单元测试只是利用@Test注解把代码或者整个请求接口内的business做测试
-
单测的过程就很多查数据库的方法,但是没必要每次都测sql,因为sql测一遍都应该是正确的。
-
未明确单元测试由开发负责。单元测试是用于维护代码逻辑不被修改或者,修改了也不出错,不是测试的事情。
-
单测代码启动速度、效率太低
-
没有在各个环境整个工程单元测试通过
-
方法写的很大,行数很多,边update边做逻辑
-
很多公司盲目追求覆盖率
目的
- 单元测试启动效率提升
- 脱离环境,在每个环境都放心执行,不要考虑测试环境、生产环境有没有这条数据
- 维护方法核心逻辑在后续的迭代中不被错误地修改
- 用于改善和提高开发效率、编码质量、编码可读性、减少冗长的代码行
点赞再看,关注公众号:【地藏思维】给大家分享互联网场景设计与架构设计方案
掘金:地藏Kelvin https://juejin.im/user/5d67da8d6fb9a06aff5e85f7
什么是有效的单元测试
主要关键字: 有效、单元
- 有效
- 单元
- 覆盖场景
- 可重复执行
- 断言
- 不追求覆盖率
1.有效的定义
- 只测试核心的业务逻辑,如计算逻辑类(指标计算)、用户支付下单组装数据库对象和子表(检验金额)、创建采买计划表和detail表的对象(校验指标个数、金额)
- 不测用户交互的,如导出数据excel的底色、查询数据库记录
- 不测逻辑的前置校验
- 不要测试明显有用的东西。避免测试来自第三方供应商的类,特别是提供编写代码的框架的核心API的类。例如,不要测试向供应商的Hashtable类添加项、redis锁等第三方库
- 不测环境相关的,尽量脱离环境,能让单测代码在每个环境都能正确执行。
2.单元的定义
- “单元测试”中的“单元”的意思是,将每个单元设为原子和尽可能独立。
- 目的:方法小,则可能组件化地再次利用,维护逻辑在以后的迭代中不被错误的修改。若被错误修改,只要每次迭代都走全工程的单测时将会报错而被发现。
- 使得编写代码时方法职责单一,方法功能要小,方法逻辑小。也不要写多行数方法,以多个小方法组成一个长逻辑。
- 单测时不要写大测试
- 逻辑代码方法尽量不互相依赖。没有关于测试执行顺序的假设。
- 逻辑代码方法适当的小,则能容易安装/拆卸。
- 单测时没必要把全流程都测一遍,也就是不必从controller遇到的第一个business入口测。只测核心逻辑,也就是核心的每个小方法的测试。
样例:
public void updateUser(String userName,Integer age) {
// 校验
if (StringUtils.isEmpty(userName)) {
throw new RuntimeException();
}
// redis分布式锁
getRedis();
// 查询主表
selectUser();
// 查询出采买计划Detail
selectUserDetail();
// 对数据进行处理
calculateUserDetailInfo();
// 更新主表
updatePuchasePlanDb();
// 更新detail表
updatePuchasePlanDbDetail();
}
假设上述updateUser是一个Controller下的第一个business逻辑入口,用于更新用户信息,很多人的单元测试就会从updateUser这个方法开始做单元测试。但是这样就不符合有效、单元的理念。
无意义测试
- 因为如redis这些第三方库,我们是相信他是正确的,而且走redis是需要连接真实网络,所以就会依赖环境,万一网络不通,单元测试这段代码就无法通过。
- 前置校验也不用测,因为错误率和以后改动的机会比较少
- 查询数据库主表、detail表、更新也不用测试,因为都是SQL,单元测试是为了维护逻辑不变,这些sql写好一遍能正确,以后的迭代中都是正确的。
有意义测试
- 所以我们单测的时候只测数据处理的逻辑,假设数据处理逻辑如下,则对下面的3个方法每个做一个单元测试。
- 我们会认为组件式的方法能正确,组合起来就大概率正确。因为方法足够的单元,则逻辑可插拔。
- 若从头测到尾,以后迭代中逻辑改动的概率很大,断言错误概率大,这样单元测试维护的意义就很小。
private void calculateUserDetailInfo() {
// 更改公司与关联上下级关系
changeCompany();
// 更改组与关联上下级关系
changeGroup();
// 更改部门与关联上下级关系
changeDeptment();
}
错误编码案例:
private void calculateBrand() {
for (int i = 0; i < new ArrayList<>().size(); i++) {
for (int i1 = 0; i1 < new ArrayList<>().size(); i1++) {
if (new Integer(1)==1) {
} else {
}
}
}
}
这样的代码就不符合单元的概念,至少把第二个for循环写在另外一个方法里,因为单元测试中,认为测试循环中一次是正确的,就断言循环中每次都大概率正确。
3.覆盖场景
- 除了测试正常流程,还要测异常流程
- 覆盖方法正常运行,为其创建一个单测
- 覆盖if else,为同一个方法创建第二个单测
案例一 异常流程
public Integer logic2(Integer num) throws Exception {
try {
num = this.purchasePlanDetailBusinessImpl.method(num);
} catch (RuntimeException e) {
throw new Exception();
}
return ++num;
}
则对应编写:
/**
* 测试异常场景
*/
@Test(expected = Exception.class)
public void testMethodOnException() {
Integer method = this.purchasePlanBusinessImpl.logic(null);
}
4.断言
很多人的单元测试都是最后print一下,在console里面看日志或者debug看看是否正确,但是这样不足够。
- 应有对方法返回值、对象里面的成员属性做判断
- 判断是否为空或者判断金额数值或者判断异常是否符合预期
- 只测试一件事一次。只要1个断言测试一或者多个特性/行为
如下,而不是直接判断是否为空或输出到终端
@Test
public void testMethodOnNormal() {
Integer method = this.purchasePlanBusinessImpl.method(1);
Assert.assertTrue(method == 2);
}
5.可重复执行
- 目前很多操作数据库,或者内存数据库
- 操作真实数据库,有可能下次就不能被断言成功了,因为数据有可能被update
- 内存数据库虽然可以下次启动依然恢复默认的数据,但是有可能被其他人的单测操作过,导致自己的数据被错误修改
6.不盲目追求覆盖率
- 很多公司盲目追求覆盖率,说美国google覆盖多高,但是别人工资高,6点准时下班,有足够时间开发,开发前uml设计好每个方法的入参出参,在中国是没有这么多时间,都是追求快速
- 在中国大厂中,虽然有覆盖率要求,但是覆盖率只能证明你有没有写单元测试,但是单元测试写的好不好,就是另外一回事。因为有些人为了提高覆盖率,把一些无关的代码也去单元测试,如测试controller层、测试entity构造函数、utils工具类等。
- 蚂蚁金服作为样例,蚂蚁是根据项目分覆盖级别,也不是所有的项目都要覆盖率多高,一般50%就很高了,不必都过50%,本文主要推崇的是有效、单元。
- 按照本文的有效、单元的做法,是会牺牲覆盖率的,因为我们只测核心逻辑
- 不浪费时间,因为中国互联网的迭代时间非常短,所以不必盲目为覆盖率而写单元测试,单元测试的目的是提供代码质量
操作工具
- mockito:一般都能适用
- powermock:在mockito的基础上,能测试private方法,还能mock static静态方法
- @InjectMocks 用于框架new出对象,不用手动new 主要测试类
- @Mock:被设置假对象返回的调用类
- Assert.assertTrue等断言
- JSONObejct、JSONString:有时自己mock对象需要自己new ,但是这个时候我们可以写好json体转换成bean会比较方便。
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>4.3.7.RELEASE</version><!--$NO-MVN-MAN-VER$ -->
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/org.mockito/mockito-all -->
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.10.19</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.7.12</version>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/junit/junit -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.3.7.RELEASE</version><!--$NO-MVN-MAN-VER$ -->
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.3.7.RELEASE</version><!--$NO-MVN-MAN-VER$ -->
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.8</version>
<scope>provided</scope>
</dependency>
</dependencies>
@RunWith(MockitoJUnitRunner.class)
public class PurchasePlanBusinessImplTest {
@InjectMocks
private DoSomeBusinessImpl purchasePlanBusinessImpl;
@Mock
private DoSomeDetailBusinessImpl purchasePlanDetailBusinessImpl;
/**
* 正常流程
*/
@Test
public void testMethodOnNormal() {
Integer method = this.purchasePlanBusinessImpl.method(1);
Assert.assertTrue(method == 2);
}
/**
* 在某些场景
*/
@Test
public void testMethodOnXX() {
when(this.purchasePlanDetailBusinessImpl.method(anyInt())).thenReturn(1);
Integer method = this.purchasePlanBusinessImpl.logic(1);
Assert.assertTrue(method == 3);
}
影响力
效率提升
- 目前测试要么启动服务、要么单测启动spring,其实都需要时间,无论是10几秒还是几分钟都是比较久的
- 如果用mock方法,都是不需要基于sring容器,不需要自动注入就不需要解析bean关系,也不需要连接zk等环境问题。启动时间只需要1秒
- 不需要在真实数据库造数据、不需要在内存数据库写sql
- 如果测试整个工程的所有单测时,每一个类单元测试都会加载一次spring、内存数据库,导致跑整个工程都很久(实际上测试环境、回归环境都需要跑单测)
脱离环境
- 其实每个环境,无论开发联调、测试、回顾、甚至生产环境都在构建时执行单元测试
- 但是因为使用spring容器启动的方式,每个类的单测都需要启动spring,导致执行时间过长
- 也或者因为环境出现造数据问题,导致执行不成功
- mock出来的数据都是在代码实现,运行于内存中,所以不依赖中间件
方法小、行数少、职责小
- 职责小:因单元测试的规则,让写每个方法时,都有意识地写的少依赖,这样的方法就提示被其他逻辑复用的概览,而不是大方法,导致要用差不多的逻辑时,其他同事就会去复制一份代码。(例如不会在一个方法又做查询数据库、校验、计算)
- 提高方法被其他逻辑利用的概率,因为大方法很难重复利用
规范
- 单元测试类以被测类的实现类为基础加Test,如xxxBusinessImpTest
- 单元测试类需要放在test目录下,并且包名与被测类的路径一致,防止idea、sonar跑覆盖率校验时,没覆盖到对应的方法。
- 方法命名:test开头,加真正的方法名,加场景,如testMethodOnNormal、testMethodOnException、testMethodOnLackOfMoney
- 方法一般情况下都带返回值,即使没有返回值也写boolean。
- 若是流程性方法等,可以为void,如责任链设计模式时
- 必须断言,而不是print。断言值、正确与否、预期异常
- 尽可能把查数据的逻辑写在被测方法之前,被测方法只做业务逻辑处理,不做查数据,这样单测时需要mock的方法会比较少。
- 公司技术体系不一定会预留单元测试时间,很少公司愿意花时间在质量和维护上。都是赶着完成任务。
- 例如3天开发,1天单元测试,1天sonar+review,1天联调,不一定有时间做得完善。