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