怎样最有效地测试异常?
程序员文章站
2022-07-14 14:50:33
...
工作中,和同事对测试异常的最佳方法产生了分歧。
我是比较欣赏JUnit4的@Test(expected=FooException.class)的啦,觉得这样多清爽啊,多declarative啊,再不用写那么一大坨try-fail-catch了。
不过同事(以下简称S)不这么认为。他觉得try-fail-catch挺好的,价格便宜,量又足,我们一直用它。而JUnit 4和TestNG提供的这个功能容易引诱程序员犯错误。
S给提出了一个挑战:
这里面initializeSomething()的作用是初始化到某一个状态,这个过程不应该出错,而到了这个状态之后,doSomethingBad()才会抛异常。
然后他坚持认为这种情况是最普遍的情况。而用annotation虽然看上去很美,但是可能邪恶地诱惑程序员写出不准确的测试,造成false positive,比如,initializeSomething()抛了一个异常。
当然,我们对这种情况的常见程度各执己见。也没什么说的。但是,后来我想,其实,这个测试换成自然语言表达是什么呢?大概是这样吧?
那么,为什么不把这两个要求写成两个测试呢?
只要我们写测试的时候不要总想着“聪明”地实现,而是直白地用代码表示需求,不就没问题了么?
再说一说我为什么这么讨厌这个try-fail-catch。它有几个我深恶痛绝的毛病。
今天早晨,忽然灵机一动,其实,还有一个方法的。比如,在你自己的BaseTest的基类里面,你可以实现一个expectException()的函数,然后这么用:
这样,在runTest()结束前,可以检查是否存在一个exception expectation,如果有,就catch住抛出来的异常,然后进行检查。而如果没出现异常,直接就报错。这样,不就没问题了?还可以进一步抽象,弄个ExceptionExpectation的接口,这样客户代码可以灵活地登记并且重用任何的异常期待,不仅仅局限于检查异常类型和错误信息了。
当然,这是在JUnit 3.8。
我是比较欣赏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。
上一篇: 中了annotation的毒了