根据集成测试用例补充单元测试用例
在之前的测试旅程中,我们新建了测试计划并将测试用例纳入该计划来执行。以下是上述用例执行之后对添加测试计划的一个代码覆盖率。
可以看到,由于只是调用了TestPlanService的addTestPlan方法,整体这个Service类的覆盖率还是比较低的。即使在addTestPlan这个方法的内部,也是存在着不少未被测试到的业务逻辑。因此,通过单元测试来补充测试覆盖也是一种质量内建的有效方式。
补充用例1-测试计划名称重复异常
来看一下addTestPlan中中第一个if的代码。从设计上来讲,这是一个哨兵断言,当存在重复的测试计划名称时,可以直接抛异常退出,提高程序处理效率。由于集成测试中的场景是测试计划被成功创建,因此这个if判断并没有进入,而是进入了继续创建测试计划的逻辑。
因此,我们需要在此处补充一个因为测试计划名称重复导致测试计划创建失败的案例。一般来说,如果是系统测试或者集成测试,我们可以通过尝试创建两个相同名字的测试计划来验证这一逻辑。不过就单元测试来说,则可以通过模拟的方式来实现。
首先来看一下系统界定存在重复的测试计划名称的方式。在getTestPlanByName方法中,通过查询数据库的方式,验证在给定的workspace中是否存在给定的测试计划名称,如果存在则返回查询到的测试计划列表。
因此,判定是否重名的逻辑就是,数据库查询返回的列表包含的记录数是否大于0。如果大于则表明存在重名,程序抛出异常。
测试用例-第一版
因此,我们设计一个测试用例,