雷斯托姆给出了一个很好的答案。我也不太喜欢《规则》。我做了类似的事情，除了创建下面的实用工具类来提高可读性和可用性，这首先是注释的一大优点。

添加这个实用程序类:

import org.junit.Assert;

public abstract class ExpectedRuntimeExceptionAsserter {

    private String expectedExceptionMessage;

    public ExpectedRuntimeExceptionAsserter(String expectedExceptionMessage) {
        this.expectedExceptionMessage = expectedExceptionMessage;
    }

    public final void run(){
        try{
            expectException();
            Assert.fail(String.format("Expected a RuntimeException '%s'", expectedExceptionMessage));
        } catch (RuntimeException e){
            Assert.assertEquals("RuntimeException caught, but unexpected message", expectedExceptionMessage, e.getMessage());
        }
    }

    protected abstract void expectException();

}

然后，对于我的单元测试，我所需要的是这段代码:

@Test
public void verifyAnonymousUserCantAccessPrivilegedResourceTest(){
    new ExpectedRuntimeExceptionAsserter("anonymous user can't access privileged resource"){
        @Override
        protected void expectException() {
            throw new RuntimeException("anonymous user can't access privileged resource");
        }
    }.run(); //passes test; expected exception is caught, and this @Test returns normally as "Passed"
}

我从来不喜欢用Junit断言异常的方式。如果我在注释中使用“预期”，从我的观点来看，我们似乎违反了“给定，当，然后”模式，因为“然后”被放置在测试定义的顶部。

同样，如果我们使用“@Rule”，我们必须处理大量的样板代码。所以，如果你可以为你的测试安装新的库，我建议你看看AssertJ(这个库现在随SpringBoot一起来了)

然后是一个不违反“给定/当/然后”原则的测试，并使用AssertJ来验证:

1 -例外是我们所期待的。 2 -它也有一个预期的信息

会是这样的:

 @Test
void should_throwIllegalUse_when_idNotGiven() {

    //when
    final Throwable raisedException = catchThrowable(() -> getUserDAO.byId(null));

    //then
    assertThat(raisedException).isInstanceOf(IllegalArgumentException.class)
            .hasMessageContaining("Id to fetch is mandatory");
}

你必须使用@Test(expected=SomeException.class)吗?当我们必须断言异常的实际消息时，这就是我们所做的。

@Test
public void myTestMethod()
{
  try
  {
    final Integer employeeId = null;
    new Employee(employeeId);
    fail("Should have thrown SomeException but did not!");
  }
  catch( final SomeException e )
  {
    final String msg = "Employee ID is null";
    assertEquals(msg, e.getMessage());
  }
}

实际上，最好的用法是try/catch。为什么?因为您可以控制异常发生的位置。

想想这个例子:

@Test (expected = RuntimeException.class)
public void someTest() {
   // test preparation
   // actual test
}

如果有一天代码被修改，测试准备将抛出RuntimeException，该怎么办?在这种情况下，实际的测试甚至没有测试，即使它没有抛出任何异常，测试也会通过。

这就是为什么使用try/catch比依赖注释要好得多的原因。

@Test (expectedExceptions = ValidationException.class, expectedExceptionsMessageRegExp = "This is not allowed")
public void testInvalidValidation() throws Exception{
     //test code
}

你可以使用@Rule注释和ExpectedException，就像这样:

@Rule
public ExpectedException expectedEx = ExpectedException.none();

@Test
public void shouldThrowRuntimeExceptionWhenEmployeeIDisNull() throws Exception {
    expectedEx.expect(RuntimeException.class);
    expectedEx.expectMessage("Employee ID is null");

    // do something that should throw the exception...
    System.out.println("=======Starting Exception process=======");
    throw new NullPointerException("Employee ID is null");
}

注意，ExpectedException文档中的例子(目前)是错误的——没有公共构造函数，所以你必须使用ExpectedException.none()。