Mockito gives UnfinishedVerificationException when it seems OK

Unit TestingJunitMockitoJunit5

Unit Testing Problem Overview


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

Unit Testing Solutions


Solution 1 - Unit Testing

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

Solution 2 - Unit Testing

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.

Solution 3 - Unit Testing

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

Solution 4 - Unit Testing

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++
    }

Solution 5 - Unit Testing

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

Solution 6 - Unit Testing

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.

Solution 7 - Unit Testing

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.

Solution 8 - Unit Testing

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
    }
}

Solution 9 - Unit Testing

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.

Solution 10 - Unit Testing

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
}

Solution 11 - Unit Testing

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

Solution 12 - Unit Testing

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.

Solution 13 - Unit Testing

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

Hope that helps someone..

Solution 14 - Unit Testing

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 this https://html.developreference.com/article/15741255/Mocked+Spring+%23Service+that+has+%23Retryable+annotations+on+methods+fails+with+UnfinishedVerificationException.

Solution 15 - Unit Testing

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.

Solution 16 - Unit Testing

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

Solution 17 - Unit Testing

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

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionJonathanView Question on Stackoverflow
Solution 1 - Unit TestingBabken VardanyanView Answer on Stackoverflow
Solution 2 - Unit TestingSteveMellrossView Answer on Stackoverflow
Solution 3 - Unit TestingMatt KleinView Answer on Stackoverflow
Solution 4 - Unit TestinghtafoyaView Answer on Stackoverflow
Solution 5 - Unit Testings1m0nw1View Answer on Stackoverflow
Solution 6 - Unit Testinguser7431997View Answer on Stackoverflow
Solution 7 - Unit TestingGeniyView Answer on Stackoverflow
Solution 8 - Unit TestingYamashiro RionView Answer on Stackoverflow
Solution 9 - Unit TestingVan KeView Answer on Stackoverflow
Solution 10 - Unit TestingBen-JView Answer on Stackoverflow
Solution 11 - Unit TestingNorman David ValenciaView Answer on Stackoverflow
Solution 12 - Unit TestingHaim RamanView Answer on Stackoverflow
Solution 13 - Unit TestingspeedygonzalesView Answer on Stackoverflow
Solution 14 - Unit TestingSandeepView Answer on Stackoverflow
Solution 15 - Unit TestingEstebanView Answer on Stackoverflow
Solution 16 - Unit TestingSamView Answer on Stackoverflow
Solution 17 - Unit TestingArtem ObukhovView Answer on Stackoverflow