对于5之前的JUnit版本:

使用AssertJ fluent断言3.7.0:

Assertions.assertThatCode(() -> toTest.method())
    .doesNotThrowAnyException();

更新:

JUnit 5引入了assertDoesNotThrow()断言，所以我更喜欢使用它，而不是向项目添加额外的依赖项。详情请看这个答案。

对于5之前的JUnit版本:

使用AssertJ fluent断言3.7.0:

Assertions.assertThatCode(() -> toTest.method())
    .doesNotThrowAnyException();

更新:

JUnit 5引入了assertDoesNotThrow()断言，所以我更喜欢使用它，而不是向项目添加额外的依赖项。详情请看这个答案。

你可以基于junit的断言创建你自己的任何类型的断言，因为这些断言是专门为创建用户定义的断言而设计的，其工作方式与junit的断言完全一样:

static void assertDoesNotThrow(Executable executable) {
    assertDoesNotThrow(executable, "must not throw");
}
static void assertDoesNotThrow(Executable executable, String message) {
    try {
        executable.execute();
    } catch (Throwable err) {
        fail(message);
    }
}

现在测试所谓的场景methodMustNotThrow，并以junit风格记录所有失败:

//test and log with default and custom messages
//the following will succeed
assertDoesNotThrow(()->methodMustNotThrow(1));
assertDoesNotThrow(()->methodMustNotThrow(1), "custom facepalm");
//the following will fail
assertDoesNotThrow(()->methodMustNotThrow(2));
assertDoesNotThrow(()-> {throw new Exception("Hello world");}, "message");
//See implementation of methodMustNotThrow below

一般来说，在任何场景中，只要调用fail(someMessage)是有意义的，就有可能立即使测试中的任何内容失败，而fail(someMessage)正是为此目的而设计的。例如，在try/catch块中使用它，如果在测试用例中抛出任何东西，就会失败:

try{methodMustNotThrow(1);}catch(Throwable e){fail("must not throw");}
try{methodMustNotThrow(1);}catch(Throwable e){Assertions.fail("must not throw");}

这是我们测试的方法的样本，假设我们有这样一个方法，在特定的情况下一定不会失败，但它可以失败:

void methodMustNotThrow(int x) throws Exception {
    if (x == 1) return;
    throw new Exception();
}

上述方法是一个简单的示例。但这适用于复杂的情况，在这种情况下，失败不是那么明显。 这里有进口:

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.function.Executable;
import static org.junit.jupiter.api.Assertions.*;

我遇到了同样的情况，我需要检查异常是否在应该抛出的时候抛出，并且仅在应该抛出的时候抛出。 最终使用异常处理程序对我的好处如下代码:

    try {
        functionThatMightThrowException()
    }catch (Exception e){
        Assert.fail("should not throw exception");
    }
    RestOfAssertions();

对我来说，主要的好处是它非常直截了当，并且在相同的结构中检查“如果且仅当”的另一种方式非常容易

你想错了。只需测试您的功能:如果抛出异常，测试将自动失败。如果没有抛出异常，您的测试将全部显示为绿色。

我注意到这个问题有时会引起人们的兴趣，所以我将展开一点。

单元测试的背景

当您在进行单元测试时，为自己定义工作单元是很重要的。基本上:对代码库的提取，可能包含也可能不包含表示单个功能的多个方法或类。

或者，正如Roy Osherove在《单元测试的艺术》第二版第11页中定义的那样:

单元测试是一段自动的代码，它调用被测试的工作单元，然后检查关于该单元的单个最终结果的一些假设。单元测试几乎总是使用单元测试框架编写的。它易于编写，运行迅速。它是可靠的、可读的和可维护的。只要生产代码没有改变，它的结果是一致的。

重要的是要认识到一个工作单元通常不只是一个方法，但在最基本的层面上它是一个方法，之后它被其他工作单元封装。

理想情况下，您应该为每个单独的工作单元都有一个测试方法，这样您就可以立即查看哪里出了问题。在这个例子中，有一个名为getUserById()的基本方法，它将返回一个用户，总共有3个单元的工作。

第一个工作单元应该测试在有效和无效输入的情况下是否返回有效用户。 数据源抛出的任何异常都必须在这里处理:如果没有用户，则应该通过测试来证明在找不到用户时抛出了异常。这个例子可以是@Test(expected = IllegalArgumentException.class)注释捕获的IllegalArgumentException。

一旦您处理了这个基本工作单元的所有用例，您就可以提升一个级别。这里的操作与此完全相同，但是只处理来自当前级别下一层的异常。这使您的测试代码保持良好的结构，并允许您快速运行整个体系结构以找到问题所在，而不必到处跳来跳去。

处理测试的有效和错误输入

现在应该很清楚如何处理这些异常了。输入有两种类型:有效输入和错误输入(严格意义上的输入是有效的，但它不是正确的)。

当您使用有效输入时，您正在设置隐式期望，即无论您编写什么测试，都将工作。

这样的方法调用看起来像这样:existingUserById_ShouldReturn_UserObject。如果这个方法失败了(例如:抛出一个异常)，那么你就知道出错了，可以开始挖掘了。

通过添加另一个使用错误输入并期望异常的测试(nonExistingUserById_ShouldThrow_IllegalArgumentException)，您可以查看您的方法是否对错误输入执行了它应该执行的操作。

博士TL;

您试图在测试中做两件事:检查有效输入和错误输入。通过将它分成两个方法，每个方法做一件事，您将有更清晰的测试，并更好地了解哪里出了问题。

通过记住分层的工作单元，您还可以减少对层次结构中较高层次的层所需的测试量，因为您不必考虑较低层次中可能出错的每一件事:当前层以下的层是您的依赖项工作的虚拟保证，如果出现错误，它在当前层中(假设较低层次本身不抛出任何错误)。

用void方法来测试场景

void testMeWell() throws SomeException {..}

不抛出异常:

Junit5

assertDoesNotThrow(() -> {
    testMeWell();
});