pringboot 单元测试 空指针_MeterSphere单元测试MockitoInline出场

根据集成测试用例补充单元测试用例

在之前的测试旅程中,我们新建了测试计划并将测试用例纳入该计划来执行。以下是上述用例执行之后对添加测试计划的一个代码覆盖率。

111747fce0fe8d735ffb75e6cad97e31.png

可以看到,由于只是调用了TestPlanService的addTestPlan方法,整体这个Service类的覆盖率还是比较低的。即使在addTestPlan这个方法的内部,也是存在着不少未被测试到的业务逻辑。因此,通过单元测试来补充测试覆盖也是一种质量内建的有效方式。

补充用例1-测试计划名称重复异常

来看一下addTestPlan中中第一个if的代码。从设计上来讲,这是一个哨兵断言,当存在重复的测试计划名称时,可以直接抛异常退出,提高程序处理效率。由于集成测试中的场景是测试计划被成功创建,因此这个if判断并没有进入,而是进入了继续创建测试计划的逻辑。

f9b27cc229384e5c29cb7ba5bed80d7a.png

因此,我们需要在此处补充一个因为测试计划名称重复导致测试计划创建失败的案例。一般来说,如果是系统测试或者集成测试,我们可以通过尝试创建两个相同名字的测试计划来验证这一逻辑。不过就单元测试来说,则可以通过模拟的方式来实现。

首先来看一下系统界定存在重复的测试计划名称的方式。在getTestPlanByName方法中,通过查询数据库的方式,验证在给定的workspace中是否存在给定的测试计划名称,如果存在则返回查询到的测试计划列表。

e09da8b5139c12c3b37f83389c1e5acc.png

因此,判定是否重名的逻辑就是,数据库查询返回的列表包含的记录数是否大于0。如果大于则表明存在重名,程序抛出异常。

测试用例-第一版

因此,我们设计一个测试用例,

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值