Why does Mockito throw `org.mockito.exceptions.verification.WantedButNotInvoked` when using `VerificationModeFactory.times(2)` in tests?

General Discussions
, ,
1

While verifying a mocked method call with VerificationModeFactory.times(2), Mockito throws WantedButNotInvoked: Wanted but not invoked: serviceService.getServices() when all tests in the class are executed together. However, each test passes individually or when the verification count is removed. Why does this exception occur in Mockito, and how can you ensure consistent verification across multiple test runs?

2

I’ve definitely run into this issue before! The org.mockito.exceptions.verification.wantedbutnotinvoked exception typically happens when Mockito expects a mocked method to be called a specific number of times, but it’s not. When you use VerificationModeFactory.times(2), it’s saying that the method should have been invoked twice, but it wasn’t, that’s what triggers this error.

Now, here’s the kicker: your tests might pass individually, but when run together, they fail. That usually points to state leakage between tests. For instance, if you’re using shared mocks that aren’t reset between tests, their state can carry over, leading to inconsistent results. So, to solve this, I recommend making sure that your mocks are reset or recreated before each test. Here’s how you can do that:

@Mock
private ServiceService serviceService;

@Before
public void setUp() {
    MockitoAnnotations.openMocks(this);
}

Or, if you’re using JUnit 5, use the @ExtendWith(MockitoExtension.class) annotation to handle the mock lifecycle automatically. This will ensure each test has its own clean slate, avoiding the org.mockito.exceptions.verification.wantedbutnotinvoked exception.

3

Absolutely, I second what Rima mentioned about test isolation being a key factor. I’ve also found that when debugging, switching from times(2) to atLeastOnce() temporarily can help. This lets you check if the method is even being called in the first place. Sometimes, the method is only invoked under specific conditions that aren’t always obvious, like conditional setup logic in the test.

So, if you are seeing the org.mockito.exceptions.verification.wantedbutnotinvoked error, it might help to check your test setup. Does the mock method get called in every scenario, or is it possible that certain paths in the test setup aren’t triggering that method as expected?

4

Exactly, @mark-mazay ! Another thing I’ve noticed is that sometimes, if the class under test is cached or reused across tests, previous test method calls can affect the current ones. That can make verification tricky since past test state can interfere with the count of invocations.

One trick I use is to explicitly reset mocks after each test to ensure that there’s no leftover state messing things up. This will also prevent any issues like org.mockito.exceptions.verification.wantedbutnotinvoked from cropping up:

@After
public void tearDown() {
    Mockito.reset(serviceService);
}

This ensures that every test starts fresh, preventing that pesky exception and giving you consistent results when using exact call counts like VerificationModeFactory.times(2).