单元测试新手上路——个人实践总结

举报
云端小宅女 发表于 2021/07/27 17:13:23 2021/07/27
【摘要】 代码设计要遵循一个重要的原则-易于修改,并且要实现这个目标就应该经常修改它,而不是等到大量积累了臃肿代码之后再进行深度重构。

最近在做安全生产专项,写了很多单测case。由于之前的工作中没有很强制要求写单元测试,一般是由测试人员去写自动化测试,因此对单测的写法不是很熟。在参考其他项目中的测试用例后,慢慢开始尝试写,这个过程中,也积累和总结了一些个人的经验,在此分享出来,欢迎大家指正和补充。

前言:为什么要写单测?

软件要易于修改

最近在看一本书《代码整洁之道:程序员的职业素养》,这本书里面说到,代码设计要遵循一个重要的原则-易于修改,并且要实现这个目标就应该经常修改它,而不是等到大量积累了臃肿代码之后再进行深度重构。

一套完善的测试用例是修改代码的安全保障

而如何保证在频繁修改优化代码之后,不影响其原本的功能呢?那就是要编写一套完善的测试用例,能覆盖到所有的链路场景,通过测试用例的执行结果来确保代码修改的正确性。

特别是我们做金融场景业务的开发,尤其要注意代码的正确性、安全性,那么写好单测是不可或缺的。

一、写单测前要做的准备

了解你的业务流程

写单测的基本前提是,你得足够熟悉你要测试的链路流程,正常执行的流程,以及异常及相应处理。

另外,还需要清楚,什么样的结果能代表代码流程按预期执行了,比如对方法返回结果的断言,对数据库生成记录的校验等。

梳理外部交互及数据变动点
如:

  • 对外RPC调用
  • MQ消息的发送、消费
  • 对数据库的插入、修改、删除

二、使用Mockito进行Mock

Mockito注解

Mockito提供了几个注解,包括@Mock、@Spy、@MockBean、@SpyBean,用于声明式地构造待Mock对象,只有被Mockito代理的对象才能进行后续的方法行为mock。

@Spy 和 @SpyBean的区别、@Mock 和 @MockBean的区别

@Spy 和 @Mock 生成的对象不受Spring管理,而 @SpyBean 和 @MockBean 会生成SpringBean,可进行自动注入。

@Spy 调用真实方法时,其依赖的其它bean是无法通过Spring自动注入的,要使用注入,要使用 @SpyBean

@MockBean 和 @SpyBean 的区别

默认行为的不同:对于未指定mock的方法,spy默认会调用真实的方法,有返回值的返回真实的返回值,而mock默认不执行,有返回值的,默认返回null。

对于某些待测类,如果我们只想Mock其某一个方法,而其他方法希望按原来正常调用,那么就应该使用@Spy或@SpyBean,而对于想要完全屏蔽原本行为的类,则使用@Mock或@MockBean来声明。

注意:使用@MockBean时,通过Mockito.when().thenReturn()来模拟方法返回,但是使用@SpyBean时,这样写会调到真实的方法,需要Mockito.doReturn().when().xxx()来声明模拟。

像我们目前在SpringBoot框架环境下开发的话,一般使用@MockBean和@SpyBean即可

Mock对象行为

Mock方法返回值

// 声明userService在传入任意参数调用get()方法时,返回user
Mockito.when(userService.get(Mockito.any())).thenReturn(user);
Mockito.doReturn(user).when(userService).get(Mockito.any());	// Spy必须用这种

Mock异常抛出

// 声明userService在传入任意参数调用get()方法时,抛出指定异常
Mockito.when(userService.get(Mockito.any())).thenThrow(new RuntimeException("mock error"));
Mockito.doThrow(new RuntimeException("mock error")).when(userService).get(Mockito.any()); // Spy必须用这种

其他的Mock编写可参考官方文档:MockitoDoc

三、写单测的注意点

每个用例聚焦测试方法的内部逻辑,不关注外部及上下游

  • 比如转账接口的单测,我应该主要关注同步接口中的受理过程,受理流程完成后的异步过程,最好不要在当前流程中提现,而应该另外再对异步实际调用方法写Case。

  • 消息消费和定时任务最好是针对最后实际调用的Service方法进行测试。

单测不能影响外部应用和数据

  • 对外请求的Rpc调用要Mock掉,如果业务流程会根据对外调用的结果有所变化,要在多个Case中分别Mock不同的返回结果

  • 避免对非测试数据和服务的影响

    关闭Mq消息生产和消费
    排除消息中间件配置类,这样Producer和Consumer都不会初始化:

    关闭Dubbo服务注册

    视情况关闭定时任务

  • Mock的数据要有标识性

测试参数和数据库准备数据一定不要对实际数据产生影响,在一些关键属性,不如id、requestNo等唯一标示要能明确区分是测试数据,并且要易于清理。但注意要符合实际情况,能代表真实场景。
————————————————
版权声明:本文为CSDN博主「未完成交响曲-KyleWang」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/wk52525/article/details/119106436

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。