我正在测试一个带有预期异常的方法.我还需要验证在抛出异常后(在模拟对象上)调用了一些清理代码，但看起来验证被忽略了.这是代码.我正在使用 Junit ExpectedException Rule 来验证预期的异常.
I am testing a method with an expected exception. I also need to verify that some cleanup code was called (on a mocked object) after the exception is thrown, but it looks like that verification is being ignored. Here is the code. I am using the Junit ExpectedException Rule to verify the expected exception.
@Rule
public ExpectedException expectedEx = ExpectedException.none();
@Test
public void testExpectedException()
{
MockedObject mockObj = mock(MockedObj.class);
MySubject subject = new MySubject(mockedObj);
expectedEx.expect(MyException.class);
expectedEx.expectMessage("My exception message.");
subject.someMethodThrowingException();
verify(mockObj).
someCleanup(eq(...));
}
似乎 verify 完全被忽略了.无论我在 verify 中输入什么方法，我的测试都通过了，这不是我想要的.
It seems like the verify is totally being ignored. No matter what method I put in the verify, my test is passing, which is not what I want.
知道为什么会这样吗?
ExpectedException 由 通过 github.com/junit-team/junit/blob/master/src/main/java/org/junit/rules/TestRule.java" rel="noreferrer">JUnit @Rule.当您的代码抛出异常时，它会向上堆栈到最近的 try/catch，这恰好位于 ExpectedException 实例中(它会检查它是否是您期望的异常).
ExpectedException works by wrapping your entire test method in a try-catch block via a JUnit @Rule. When your code throws an exception, it goes up the stack to the nearest try/catch, which happens to be in the ExpectedException instance (which checks that it is the exception you're expecting).
在 Java 中，如果方法中发生未捕获的异常，则控制权将永远不会返回到该方法中稍后的语句.此处适用相同的规则:在异常发生后，控制永远不会返回到测试中的语句.
In Java, if an uncaught exception occurs in a method, control will never return to statements later in that method. The same rules apply here: Control never returns to the statements in your test after the exception.
从技术上讲，您可以将验证放在 finally 块中，但这往往是 一个坏习惯.您的被测系统可能会抛出意外异常，或者根本没有异常，这将为您提供有用的失败消息和跟踪；但是，如果该失败导致您的验证或断言在 finally 块中失败，那么 Java 将显示这一点，而不是有关意外异常或意外成功的消息.这会使调试变得困难，尤其是因为您的错误将来自错误根本原因之后的代码行，错误地暗示上面的代码已成功.
Technically, you could put the verifications in a finally block, but that tends to be a bad habit. Your system-under-test might throw an unexpected exception, or no exception at all, which would give you a helpful failure message and trace; however, if that failure then causes your verifications or assertions to fail in the finally block, then Java will show that rather than a message about the unexpected exception or unexpected success. This can make debugging difficult, especially because your error will come from lines of code following the root cause of the error, incorrectly implying that the code above it succeeded.
如果您确实需要在异常发生后验证状态，则可以基于每个方法，随时恢复到这个习惯用法:
If you really need to verify state after the exception, on a per-method basis, you can always revert back to this idiom:
@Test
public void testExpectedException()
{
MockedObject mockObj = mock(MockedObj.class);
MySubject subject = new MySubject(mockedObj);
try {
subject.someMethodThrowingException();
fail("Expected MyException.");
} catch (MyException expected) {
assertEquals("My exception message.", expected.getMessage());
}
verify(mockObj).someCleanup(eq(...));
}
更新:使用 Java 8 的 lambda 表达式，您可以将函数式接口调用包装在 try 块中 简洁到有用.我想对这种语法的支持会在许多标准测试库中找到.
Update: With Java 8's lambda expressions, you can wrap a functional interface call in a try block concisely enough to be useful. I imagine support for this syntax will find its way into many standard testing libraries.
assertThrows(MyException.class,
() -> systemUnderTest.throwingMethod());
这篇关于异常Junit 4.10后的Mockito验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！