使用JUnit的ExpectedException和@Rule测试自定义异常

为什么要测试异常流？ 就像所有代码一样，测试覆盖率会在代码和应该生成的业务功能之间写一个合同，从而为您提供代码的有效文档 ，以及增加的尽早且经常强调功能的功能。 我不会介绍测试的许多好处，而是只关注异常测试。

有很多方法可以测试从一段代码引发的异常流。 假设您有一个受保护的方法，该方法要求参数不为null。 您将如何测试该状况？ 引发异常时，如何防止JUnit报告失败？ 该博客涵盖了几种不同的方法使用JUnit的的ExpectedException使用JUnit的@rule功能实现的高潮。

“旧”方式

在不久的将来，测试异常的过程需要大量的样板代码，您可以在其中启动try / catch块，如果代码未产生预期的行为，则报告失败，然后捕获异常以查找异常。具体类型。 这是一个例子：

public class MyObjTest {
 
    @Test
    public void getNameWithNullValue() {
 
        try {
            MyObj obj = new MyObj();
            myObj.setName(null);
            
            fail('This should have thrown an exception');
 
        } catch (IllegalArgumentException e) {
            assertThat(e.getMessage().equals('Name must not be null'));
        }
    }
}

从这个旧示例中可以看到，测试用例中的许多行只是为了支持缺少专门测试异常处理的功能。 使用try / catch方法的一个好处是可以测试特定消息和预期异常上的任何自定义字段 。 我们将通过JUnit的ExpectedException和@Rule注释进一步探讨这一点。