1700453220
//断言100除以10的结果为10
1700453221
1700453222
assertEquals(10,foo.divid(100,10));
1700453223
1700453224
}
1700453225
1700453226
//边界测试场景
1700453227
1700453228
@Test
1700453229
1700453230
public void testDividBroader(){
1700453231
1700453232
//断言最大值除以最小值结果为0
1700453233
1700453234
assertEquals(0,foo.divid(Integer.MAX_VALUE, Integer.MIN_VALUE));
1700453235
1700453236
//断言最小值除以最大值结果为-1
1700453237
1700453238
assertEquals(-1,foo.divid(Integer.MIN_VALUE, Integer.MAX_VALUE));
1700453239
1700453240
}
1700453241
1700453242
//异常测试场景
1700453243
1700453244
@Test(expected=ArithmeticException.class)
1700453245
1700453246
public void testDividException(){
1700453247
1700453248
//断言除数为0时抛出ArithmeticException
1700453249
1700453250
foo.divid(100,0);
1700453251
1700453252
//断言不会执行到这里
1700453253
1700453254
fail();
1700453255
1700453256
}
1700453257
1700453258
}
1700453259
1700453260
诸位可以看到这么简单的一个除法计算就需要如此多的测试代码,如果在生产代码中再加入就if、switch等判断语句,那它所需要的测试场景就会更加复杂了。只要有一个判断条件,就必须有两个测试场景(条件为真的场景和条件为假的场景),这也是在项目中的测试覆盖率不能达到100%的一个主要原因:单元测试的代码量远大于生产代码。通常在项目中,单元测试覆盖率很难达到60%,因为不能100%覆盖,这就导致了代码测试的不完整性,隐藏的缺陷也就必然存在了。
1700453261
1700453262
(2)代码整合错误是不可避免的
1700453263
1700453264
单元测试只是保证了分割的独立单元的正确性,它不能保证一个功能的完整性。单元测试首先会假设所有的依赖条件都满足,但真实情况并不是这样的,我们经常会发现虽然所有的单元测试都通过了,但在进行整合测试时仍然会产生大量的业务错误—很多情况下,此种错误是因为对代码的职责不清晰而引起的,这属于认知范畴,不能通过单元测试避免。
1700453265
1700453266
(3)部分代码无法(或很难)测试
1700453267
1700453268
如果把如下代码放置在一个多线程的环境下,思考一下该如何测试呢?代码如下:
1700453269
[
上一页 ]
[ :1.70045322e+09 ]
[
下一页 ]