JUnit4 @Test(expected = MyException.class)VS try/catch

Question

我正在考虑异常处理和单元测试最佳实践,因为我们正在努力获得一些代码最佳实践.

我们公司维基上发现的前一篇关于最佳实践的文章指出"不要使用try/catch,而是使用Junit4 @Test(expect = MyException.class)",没有进一步的信息.我不相信.

我们的许多自定义异常都有一个枚举,以便识别失败原因.结果,我宁愿看到如下的测试:

@Test
public void testDoSomethingFailsBecauseZzz() {
try{
   doSomething();
} catch(OurCustomException e){
   assertEquals("Omg it failed, but not like we planned", FailureEnum.ZZZ, e.getFailure());
}
}

比:

@Test(expected = OurCustomException.class)
public void testDoSomethingFailsBecauseZzz() {
   doSomething();
}

当doSomethig()看起来像:

public void doSomething throws OurCustomException {
  if(Aaa) {
     throw OurCustomException(FailureEnum.AAA);
  } 
  if(Zzz) {
     throw OurCustomException(FailureEnum.ZZZ);
  }
  // ...
}

在旁注中,我更确信在某些情况下@Test(expected = blabla.class)是最佳选择(例如,当异常是精确的并且毫无疑问导致它的原因时).

我在这里遗漏了什么,还是应该在必要时推动使用try/catch？

Answer 1

听起来你的枚举被用作异常层次结构的替代品？也许如果你有一个异常层次结构,@Test(expected=XYZ.class)那么它会变得更有用吗？

Answer 2

• 如果您只想检查是否抛出了某种类型的异常,请使用注释的expected属性.
• 如果要检查抛出异常的属性(例如消息或自定义成员值),请在测试中捕获它并进行断言.

在你的情况下,似乎你想要后者(断言异常有一定的FailureEnum值); 使用它没有任何问题try/catch.

你应该"不使用try/catch"(解释为"从不")的概括是无聊的.

杰夫是对的; 您的异常层次结构的组织是可疑的.但是,你似乎认识到这一点.:)