软件要易于修改
最近在看一本书《代码整洁之道:程序员的职业素养》,这本书里面说到,代码设计要遵循一个重要的原则-易于修改,并且要实现这个目标就应该经常修改它,而不是等到大量积累了臃肿代码之后再进行深度重构。
完善的测试用例是修改代码的安全保障
而如何保证在频繁修改优化代码之后,不影响其原本的功能呢?那就是要编写一套完善的测试用例,能覆盖到所有的链路场景,通过测试用例的执行结果来确保代码修改的正确性。
特别是我们做金融场景业务的开发,尤其要注意代码的正确性、安全性,那么写好单测是不可或缺的。
了解你的业务流程
写单测的基本前提是,你得足够熟悉你要测试的链路流程,正常执行的流程,以及异常及相应处理。
另外,还需要清楚,什么样的结果能代表代码流程按预期执行了,比如对方法返回结果的断言,对数据库生成记录的校验等。
梳理外部交互及数据变动点
如:
对外RPC调用
MQ消息的发送、消费
对数据库的插入、修改、删除
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即可。
Mockito对象行为
/ 声明userService在传入任意参数调用get()方法时,返回user
Mockito.when(userService.get(Mockito.any())).thenReturn(user);
Mockito.doReturn(user).when(userService).get(Mockito.any()); // Spy必须用这种
// 声明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必须用这种
用例聚焦内部逻辑,不关注外部及上下游
比如转账接口的单测,我应该主要关注同步接口中的受理过程,受理流程完成后的异步过程,最好不要在当前流程中提现,而应该另外再对异步实际调用方法写Case。
消息消费和定时任务最好是针对最后实际调用的Service方法进行测试。
单测不能影响外部应用和数据
比如风控Accept和风控Pending后的流程截然不同,那么就要分别创建Case,并Mock不同结果。
关闭Dubbo服务注册
视情况关闭定时任务
| 此部分仅做基础示例,基于新加坡建站技术栈:Doggy(SpringCloudAlibaba) + Acts (AntCoreTestSuite)2.0
Acts介绍
ACTS 源于蚂蚁集团多年金融级分布式架构工程的测试实践积累与沉淀,为企业提供高效、精细化的接口自动化测试。
ACTS是一款基于数据驱动测试执行的蚂蚁内部自研测试框架,适配 SOFA、SOFABoot 的测试环境。它的用例数据以静态文件为载体,在此基础上构建用例模型驱动测试执行,并依赖框架内定义的一套标准化测试流程自动编排用例整个生命周期,同时实现了可视化编辑、高效化用例管理、精细化结果校验等,可以极大压缩测试代码体积。
简单实践
注意,对抛出异常的校验可以在Result内声明具体异常,跟正常结果对象一样声明即可。