欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

怎样最有效地测试异常?

程序员文章站 2022-07-14 14:50:33
...
工作中,和同事对测试异常的最佳方法产生了分歧。

我是比较欣赏JUnit4的@Test(expected=FooException.class)的啦,觉得这样多清爽啊,多declarative啊,再不用写那么一大坨try-fail-catch了。

不过同事(以下简称S)不这么认为。他觉得try-fail-catch挺好的,价格便宜,量又足,我们一直用它。而JUnit 4和TestNG提供的这个功能容易引诱程序员犯错误。

S给提出了一个挑战:

public void testDoSomethingBad() {
  initializeSomething();
  try {
    doSomethingBad();
    fail();
  } catch (FooException e) {}
}


这里面initializeSomething()的作用是初始化到某一个状态,这个过程不应该出错,而到了这个状态之后,doSomethingBad()才会抛异常。

然后他坚持认为这种情况是最普遍的情况。而用annotation虽然看上去很美,但是可能邪恶地诱惑程序员写出不准确的测试,造成false positive,比如,initializeSomething()抛了一个异常。

当然,我们对这种情况的常见程度各执己见。也没什么说的。但是,后来我想,其实,这个测试换成自然语言表达是什么呢?大概是这样吧?
  • initializeSomething()不许出错
  • 在initializeSomething()之后doSomethingBad()要出错


那么,为什么不把这两个要求写成两个测试呢?
@Test
public void testInitializeSomething() {
  initializeSomething();
}

@Test(expected=FooException.class)
public void testDoSomethingBadAfterInitializeSomething() {
  initializeSomething();
  doSomethingBad();
}


只要我们写测试的时候不要总想着“聪明”地实现,而是直白地用代码表示需求,不就没问题了么?

再说一说我为什么这么讨厌这个try-fail-catch。它有几个我深恶痛绝的毛病。
  • 它等于代码里的逻辑分支。如果没有抛异常,它执行fail(),而如果抛了异常,它进入catch()。而测试里的逻辑分支味道很坏。它让你的代码容易出错(比如,你忘了fail怎么办?测试一样是绿的,但是你的bug还躲在那)。而且,它让测试代码不能达到100%的分支覆盖率。本来如果用annotation的话,如果出现了initializeSomething()抛出异常的情况,覆盖率马上不是100%了,你可以很容易地发现问题。
  • 冗长烦琐。测试写的不象spec,而象过程形代码。
  • 这个try-fail-catch只在你检查Exception的时候成立。如果万一你要检查一个Error甚至是JUnit的AssertionFailedError,完了,你连fail()抛的异常也给截获了。


今天早晨,忽然灵机一动,其实,还有一个方法的。比如,在你自己的BaseTest的基类里面,你可以实现一个expectException()的函数,然后这么用:
public void testDoSomethingBad() {
  initializeSomething();
  expectException(FooException.class);
  doSomethingBad();
}


这样,在runTest()结束前,可以检查是否存在一个exception expectation,如果有,就catch住抛出来的异常,然后进行检查。而如果没出现异常,直接就报错。这样,不就没问题了?还可以进一步抽象,弄个ExceptionExpectation的接口,这样客户代码可以灵活地登记并且重用任何的异常期待,不仅仅局限于检查异常类型和错误信息了。

当然,这是在JUnit 3.8。
相关标签: junit 工作