怎样最有效地测试异常？

阅读更多

工作中，和同事对测试异常的最佳方法产生了分歧。

我是比较欣赏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。