有人想到了在Java单元测试中使用try和catch块的想法：

 @Test  public void test() { try { callSomeCode(); } catch (Exception e) { assertEquals( "foo" , e.getMessage()); }  } 

上面的内容很诱人，但不起作用 。 如果被测代码没有抛出，则不会执行任何断言。

所以要解决它：

 @Test  public void test() { try { callSomeCode(); // if we get here there was no exception fail(); } catch (Exception e) { assertEquals( "foo" , e.getMessage()); }  } 

我们添加了一个fail ，这使其完全测试了是否抛出了正确的东西，但这很尴尬。

这是测试气味 过分主张的一个例子。

有多少种方法可以测试抛出的内容？

我所知道的所有方式：

• 长远地做（上面）
• 使用@Test(expected = ... )批注检查以正确的异常结尾的测试
• 使用ExpectedException JUnit 规则 ，该规则允许您定义要结束的测试
• 使用为您捕获异常的断言

为什么预期的异常模式不起作用

此处针对长期的方法进行了解释的规则使您可以定义以异常结尾的测试功能的成功标准。

例如

 // default to expecting no exception  @Rule  public ExpectedException expectedException = ExpectedException.none();  @Test  public void test() { // the call should end in the right exception expectedException.expectMessage(is( "foo" )); // do the call callSomeCode();  } 

这很有吸引力，但仍然是错误的

给定/何时/然后发生了什么？

测试应从上至下读取，并在末尾声明。 预期的异常模式必须在产生断言/期望的调用之前定义断言/期望，这是向后的。

反过来：

 @Test  public void test() { assertThatThrownBy(() -> callSomeCode()) .hasMessage( "foo" );  } 

简洁并能向前看。

翻译自: https://www.javacodegeeks.com/2019/08/checking-whats-thrown-in-java-tests.html