Mockito gives UnfinishedVerificationException when it seems OK

Question

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());

And here's the partial class and method:

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

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

How does the class of the `classUnderTest` look like? What's the method's signature? It works fine for me with public non-final classes/methods. — Tom Verelst, Apr 09 '13 at 15:08
Is the line referred to in the message (which you've redacted) the same as the line where the exception is actually thrown? Usually, if you have unfinished verification, Mockito won't report it until the NEXT time you use a Mockito method. It may well be that your problem is in the test method immediately BEFORE this one. That's why Mockito reports the line number where the error occurs SEPARATELY from the stack trace itself. — Dawood ibn Kareem, Apr 09 '13 at 23:14
Thank-you, David. That was the problem. Would you copy your comment to an answer so I can accept? — Jonathan, Apr 10 '13 at 11:43

Babken Vardanyan · Answer 1 · 2017-05-07T11:17:54.863

116

This might also be caused if you try to verify a method which expects primitive arguments with any():

For example, if our method has this signature:

method(long l, String s);

And you try to verify it like this, it will fail with aforementioned message:

verify(service).method(any(), anyString());

Change it to anyLong() and it will work:

verify(service).method(anyLong(), anyString());

edited May 07 '17 at 11:17

answered Jun 27 '15 at 05:24

Babken Vardanyan

14,090
13
68
87

Why not pass **anyString()**? – IgorGanapolsky Apr 25 '17 at 14:10
1

@IgorGanapolsky Thanks, changed to anyString() – Babken Vardanyan May 07 '17 at 11:18
5

Voted up because this is what happened to me. The error message doesn't mention that any() can't match primitives. – harperska Apr 25 '19 at 23:59
2

This is exactly what happened to me – D.T Jan 03 '20 at 09:41
2

Thanks! This solved my problem. The error message is really misguided. – Taher Jun 09 '20 at 11:21
Thanks it solved my problem. You doesn't have to use `anyString()` for String data type. – Falcon Oct 23 '20 at 08:23
This solved my problem. I was keep getting `NullPointerException`. Sometimes message is misleading. In my case argument was `int` type and passing `any()`. By changing it to `anyInt()` fixed the issue. – Ravi Nain May 25 '21 at 00:30
Exactly the problem. Unbelievable! – kim Jun 17 '21 at 08:19
thanks. Mockito verify() gets me everytime with the confusing any() function. They should have had more explicit name.. any() sounds like it would allow anything. – saurabh.in May 12 '23 at 17:45

score 95 · Accepted Answer · edited Apr 08 '19 at 16:02

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

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();
}

From the Mockito documentation here:

Mockito throws exceptions if you misuse it so that you know if your tests are written correctly. The gotcha is that Mockito does the validation next time you use the framework (e.g. next time you verify, stub, call mock etc.). But even though the exception might be thrown in the next test, the exception message contains a navigable stack trace element with location of the defect. Hence you can click and find the place where Mockito was misused.

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.

See MockitoRule class here http://stackoverflow.com/questions/40793464/parameterized-testing-with-mockito-by-using-junit-rule — tkruse, Mar 16 '17 at 08:36

score 14 · Answer 3 · answered Oct 18 '18 at 19:01

14

I was getting this same error due to using any() with a boolean parameter, when apparently it needed to be anyBoolean().

answered Oct 18 '18 at 19:01

Matt Klein

7,856
6
45
46

score 7 · Answer 4 · answered Feb 14 '20 at 16:56

7

In my case, using kotlin was because the funcion to test was not declared as open.

The exception notices that no final/private/equals/hash methods can be used.

fun increment(){
        i++
    }

to

open fun increment(){
        i++
    }

answered Feb 14 '20 at 16:56

htafoya

18,261
11
80
104

score 5 · Answer 5 · answered Aug 09 '18 at 12:00

5

With Junit 5, you can add the following to show more meaningful Mockito exceptions in the console

@AfterEach
public void validate() {
    validateMockitoUsage()
}

Also see this answer: https://stackoverflow.com/a/22550055/8073652

answered Aug 09 '18 at 12:00

s1m0nw1

76,759
17
167
196

score 3 · Answer 6 · answered Jun 14 '16 at 07:51

I had similar exception with class MyRepository

org.mockito.exceptions.misusing.UnfinishedVerificationException: Missing method call for verify(mock) here: -> at MyRepository$$FastClassBySpringCGLIB$$de8d8358.invoke()

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

The problem was resolved when I created interface for MyRepository, and mock interface, but not implementation. It seems spring creates some CGLIB proxies and it leads to UnfinishedVerificationException exception.

score 3 · Answer 7 · answered Jan 30 '18 at 22:18

For me the issue turned out to be a missing bean declaration in the test context xml. It was for a custom aspect class used by another class, an instance of which is a parameter to the constructor of the class which is the parameter to failing verify() call. So I added the bean declaration to the context xml and it worked fine after that.

score 2 · Answer 8 · edited Feb 27 '20 at 02:43

2

Changed to @RunWith(PowerMockRunner.class) and the issue went away. Was using @RunWith(MockitoJUnitRunner.class) earlier.

Hope that helps someone..

edited Feb 27 '20 at 02:43

U13-Forward

69,221
14
89
114

answered Feb 27 '20 at 02:14

speedygonzales

169
2
7

score 2 · Answer 9 · answered Jun 15 '20 at 11:37

I had the same issue, too, on the following stack:

Kotlin
Junit 4.13
Mockito 2.28.2 + Mockito-Inline 2.13.0
Robolectric 4.3.1

I tried to verify a lambda call:

@RunWith(RobolectricTestRunner::class)
class MainViewTest {

    @get:Rule
    val mockitoRule: MockitoRule = MockitoJUnit.rule()

    @Mock private lateinit var mockClickCallback: () -> Unit

    @Test
    fun `should call clickCallback on the button click`() {
        val activity = Robolectric.buildActivity(MainActivity::class.java).create().get()
        val viewUnderTest = MainView(activity)
        viewUnderTest.setClickCallback(mockClickCallback)

        viewUnderTest.button.performClick()

        verify(mockClickCallback).invoke() // UnfinishedVerificationException
    }
}

Then I found the issue on Github, it seems that the problem is in Robolectric. I used the following workaround:

@RunWith(RobolectricTestRunner::class)
class MainViewTest {

    private interface UnitFunction: () -> Unit

    @Test
    fun `should call clickCallback on the button click`() {
        val activity = Robolectric.buildActivity(MainActivity::class.java).create().get()
        val viewUnderTest = MainView(activity)
        val mockClickCallback = mock(UnitFunction::class.java) as () -> Unit
        viewUnderTest.setClickCallback(mockClickCallback)

        viewUnderTest.button.performClick()

        verify(mockClickCallback).invoke() // OK
    }
}

score 1 · Answer 10 · edited Jan 03 '20 at 00:20

Two answers above suggested using validateMockitoUsage() method after each test.

While this is correct I found that annotating your class with @ExtendWith(MockitoExtension.class) in Junit 5 give the same effect while adding some the nice Mockito functionalities. Also, it looks cleaner to me as well.

I guess Junit 4 @RunWith(MockitoJUnitRunner.class) will give a similar result but I didn't test it.

score 0 · Answer 11 · answered May 03 '18 at 11:13

0

I had a similar problem, i found a way to solve this. Mock objects which you for verify haven't been reseted, so you should reset it .You can reset(mock) before your test case function, it may be helpful.

answered May 03 '18 at 11:13

Van Ke

1

score 0 · Answer 12 · answered Nov 19 '18 at 10:26

If you try to verify a private or package-private method with Mockito.verify you will get this error.

If you don't want to use PowerMockito you can set your method as protected and I advise you to add the @VisibleForTesting tag:

Before:

void doSomething() {
   //Some behaviour
}

After :

@VisibleForTesting
protected void doSomething() {
   //Some behaviour
}

score 0 · Answer 13 · answered Jul 23 '19 at 00:28

I was having the same error

org.mockito.exceptions.misusing.UnfinishedVerificationException: 
Missing method call for verify(mock) here:
-at com.xxx.MyTest.testRun_Should_xxx_When_yyy(MyTest.java:127)

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.
Mocking methods declared on non-public parent classes is not supported.


    at com.xxx.MyTest.validate(MyTest.java:132)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.junit.internal.runners.MethodRoadie.runAfters(MethodRoadie.java:145)
    at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:99)
...

In my case, the error was generated because I was using a PowerMockito.verifyStatic() before my Mockito.verify(...) call, then I had to move the PowerMockito.verifyStatic() to last line (or delete it).

From:

PowerMockito.verifyStatic();
Mockito.verify(myMock, Mockito.times(1)).myMockedMethod(anyString(), anyString(), anyString(), any(XXX.class), any(YYY.class), any(ZZZ.class));

To:

Mockito.verify(myMock, Mockito.times(1)).myMockedMethod(anyString(), anyString(), anyString(), any(XXX.class), any(YYY.class), any(ZZZ.class)); 
PowerMockito.verifyStatic();

score 0 · Answer 14 · edited Nov 09 '22 at 21:34

The tests run individually well but while running integration test suite it fails with the UnfinishedVerificationException. The issue arises when we use verify() from mockito and have @EnableRetry. Workaround for this is to use

public static <T> T unwrapAndVerify(T mock, VerificationMode mode) {
   return ((T) Mockito.verify(AopTestUtils.getTargetObject(mock), mode));
}

as mentioned in Mocked Spring @Service that has @Retryable annotations on methods fails with UnfinishedVerificationException

score 0 · Answer 15 · answered Mar 09 '21 at 08:58

Here is my grain of salt! I discovered there is a conflict between Mockito and Hibernate Validation. My solution is the separate my contract checks (@NotNull, @NotEmpty, etc) from the mockito tests. I also started using validateMockitoUsage() to ensure everything was run correctly.

score 0 · Answer 16 · answered Jul 13 '23 at 07:59

(In case you can also completely ignore all error hints like me)
In my case it was a misuse of the API. Code looked like this:

verify(mockedInstance.concreteMethod(), times(x));

Instead of (as docs clearly says)

verify(mockedInstance, times(x)).concreteMethod();

score -1 · Answer 17 · answered Jun 13 '18 at 08:08

I'm not sure where are your "classUnderTest" come from, but please keep sure it's mocked, not a real one. I have the same issue for my test case below:

MyAgent rpc = new MyAgent("myNodeName");
...
rpc.doSomething();
...
PowerMockito.verifyPrivate(rpc).invoke("initPowerSwitch");
PowerMockito.verifyPrivate(rpc).invoke("init", "192.168.0.23", "b2", 3);

But it's disappeared for the following test case:

MyAgent rpc = PowerMockito.spy(new MyAgent("myNodeName"));
...
rpc.doSomething();
...
PowerMockito.verifyPrivate(rpc).invoke("initPowerSwitch");
PowerMockito.verifyPrivate(rpc).invoke("init", "192.168.0.23", "b2", 3);

Attention, the Object rpc should be mocked by PowerMockito.spy(...).

score -1 · Answer 18 · answered Apr 10 '21 at 06:07

Faced same exception when used mockStatic method and called Mockito.verify multiple times, but passed interface instead of implementing class.

wrong code:

try (MockedStatic<Service> staticMock = Mockito.mockStatic(Service.class, Mockito.CALLS_REAL_METHODS)) {
  staticMock.verify(() -> ServiceImpl.method()); // passed without errors
  staticMock.verify(() -> ServiceImpl.method()); // throws UnfinishedVerificationException 
}

fixed code:

try (MockedStatic<ServiceImpl> staticMock = Mockito.mockStatic(Service.class, Mockito.CALLS_REAL_METHODS)) {
  staticMock.verify(() -> ServiceImpl.method());
  staticMock.verify(() -> ServiceImpl.method());
}

It was my mistake obviosly, but UnfinishedVerificationException message was not helpfull

Mockito gives UnfinishedVerificationException when it seems OK

18 Answers18

Linked

Related