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
1700453270
class Apple{
1700453271
1700453272
//苹果颜色
1700453273
1700453274
private int color；
1700453275
1700453276
public int getColor（）{
1700453277
1700453278
return color；
1700453279
1700453280
}
1700453281
1700453282
public void setColor（int color）{
1700453283
1700453284
this.color=color；
1700453285
1700453286
}
1700453287
1700453288
}
1700453289
1700453290
这是一个简单的JavaBean，也是我们项目中经常出现的，对于此类BO（Business Object），通常情况下是不会进行单元测试的，想必你也会想这不用测试吧，很简单嘛，就一个getter/setter方法，出错的可能性不大。但这只是我们一厢情愿的想法，如果该Apple是在多线程环境下，你还认为不会出现线程不安全的情况吗？事实上，因为没有采用资源保护措施（synchronized或Lock），多个线程共同访问该对象时就会出现不安全的情况。现在问题来了：为什么在通常情况下不做此类对象的单元测试呢？
1700453291
1700453292
比如一个JEE应用，一般情况下都是多线程环境，但是我们很少对代码进行多线程测试，原因很简单，测试很复杂，很难进行全面的多线程测试。而且如果要保证在多线程下测试通过，就必须对代码增加大量的修饰，这必然会导致代码的可读性和可维护性降低，这也是我们一般都抛弃多线程测试的原因。
[
上一页 ]
[ :1.700453243e+09 ]
[
下一页 ]