Mockito在看起来还可以的时候给出UnfinishedVerificationException

问题描述

当我认为我正确完成所有操作时，Mockito似乎正在抛出UnfinishedVerificationException.这是我的部分测试用例:

Mockito appears to be throwing an UnfinishedVerificationException when I think I've done everything correctly. Here's my partial test case:

HttpServletRequest req = mock(HttpServletRequest.class);
when(req.getHeader("Authorization")).thenReturn("foo");

HttpServletResponse res = mock(HttpServletResponse.class);

classUnderTest.doMethod(req, res); // Use the mock

verify(res, never());
verify(req).setAttribute(anyString(), anyObject());

这是部分类和方法:

class ClassUnderTest extends AnotherClass {
    @Override
    public String doMethod(ServletRequest req, ServletRequest res) {
        // etc.
        return "someString";
    }
}

忽略了您永远不应该模拟不属于您的接口的事实，为什么Mockito会给我以下消息?

Ignoring the fact that you should never mock interfaces you don't own, why is Mockito giving me the following message?

org.mockito.exceptions.misusing.UnfinishedVerificationException:
Missing method call for verify(mock) here:
-> at (redacted)

Example of correct verification:
    verify(mock).doSomething()

Also, this error might show up because you verify either of: final/private/equals()/hashCode() methods.
Those methods *cannot* be stubbed/verified.

at [test method name and class redacted]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37)
at org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
... etc

推荐答案

我刚刚遇到了这个问题，这引起了我很多困惑.

I just came across this my self and it caused me a lot of confusion.

如上文David所述，Mockito报告了 next Mockito方法调用中的错误，该错误可能不在同一测试方法中.尽管异常消息确实包含对实际位置的引用，但发生错误时，我发现有错误的测试未能使测试过程适得其反.而且测试越简单，下一次测试中出现错误的可能性就越大！

As David mentioned above Mockito reports errors in the next Mockito method call which may not be in the same test method. While the exception message does contain a reference to the actual place the error occurred I find having incorrect tests failing counter productive to the testing process. And the simpler the tests the more likely an error is to show up in the next test!

这是一个简单的修复程序，可以确保在正确的测试方法中出现错误:

Here is an easy fix that will ensure errors appear in the correct test method:

@After
public void validate() {
    validateMockitoUsage();
}

来自Mockito文档这里:

From the Mockito documentation here:

有时候，您可能会 想要明确地验证框架使用情况.例如，其中之一 用户想将validateMockitoUsage()放在他的@After方法中，这样 当他滥用Mockito时立即知道.没有它，他 早在下次使用时便会知道这一点 框架. 在@After中具有validateMockitoUsage()的另一个好处 是jUnitRunner总是会在有缺陷的测试方法中失败 而普通的下次"验证可能会在下一次测试中失败 方法.但是，即使JUnit可能会将下一个测试报告为红色，也不要 担心它，只需单击 异常消息可立即找到您滥用的地方 模仿.

Sometimes though, you might want to validate the framework usage explicitly. For example, one of the users wanted to put validateMockitoUsage() in his @After method so that he knows immediately when he misused Mockito. Without it, he would have known about it not sooner than next time he used the framework. One more benefit of having validateMockitoUsage() in @After is that jUnit runner will always fail in the test method with defect whereas ordinary 'next-time' validation might fail the next test method. But even though JUnit might report next test as red, don't worry about it and just click at navigable stack trace element in the exception message to instantly locate the place where you misused mockito.

这篇关于Mockito在看起来还可以的时候给出UnfinishedVerificationException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！