Resolving Mockito Exception: Wanted But Not Invoked

Last updated: April 10, 2025

Written by: Thibault Faure

Reviewed by: David Martinez

Testing

Mockito

Azure Container Apps is a fully managed serverless container service that enables you to build and deploy modern, cloud-native Java applications and microservices at scale. It offers a simplified developer experience while providing the flexibility and portability of containers.

Of course, Azure Container Apps has really solid support for our ecosystem, from a number of build options, managed Java components, native metrics, dynamic logger, and quite a bit more.

To learn more about Java features on Azure Container Apps, visit the documentation page.

You can also ask questions and leave feedback on the Azure Container Apps GitHub page.

Of course, Azure Container Apps has really solid support for our ecosystem, from a number of build options, managed Java components, native metrics, dynamic logger, and quite a bit more.

To learn more about Java features on Azure Container Apps, you can get started over on the documentation page.

And, you can also ask questions and leave feedback on the Azure Container Apps GitHub page.

Modern software architecture is often broken. Slow delivery leads to missed opportunities, innovation is stalled due to architectural complexities, and engineering resources are exceedingly expensive.

Orkes is the leading workflow orchestration platform built to enable teams to transform the way they develop, connect, and deploy applications, microservices, AI agents, and more.

With Orkes Conductor managed through Orkes Cloud, developers can focus on building mission critical applications without worrying about infrastructure maintenance to meet goals and, simply put, taking new products live faster and reducing total cost of ownership.

Try a 14-Day Free Trial of Orkes Conductor today.

Orkes is the leading workflow orchestration platform built to enable teams to transform the way they develop, connect, and deploy applications, microservices, AI agents, and more.

Try a 14-Day Free Trial of Orkes Conductor today.

End-to-end testing is a very useful method to make sure that your application works as intended. This highlights issues in the overall functionality of the software, that the unit and integration test stages may miss.

Playwright is an easy-to-use, but powerful tool that automates end-to-end testing, and supports all modern browsers and platforms.

When coupled with LambdaTest (an AI-powered cloud-based test execution platform) it can be further scaled to run the Playwright scripts in parallel across 3000+ browser and device combinations:

>> Automated End-to-End Testing With Playwright

1. Overview

In this tutorial, we’ll talk about a common error we can face when we use Mockito. The Exception message is:

Wanted but not invoked:
// class name and location
Actually, there were zero interactions with this mock.

Let’s understand the potential sources of this error and how to fix it.

2. Example Setup

First, let’s create the class we’ll mock later on. It contains a lone method, which always returns the String, “Baeldung”:

class Helper {
    String getBaeldungString() {
        return "Baeldung";
    }
}

Let’s now create our main class. It declares a Helper instance at the class level. We’ll want to mock this instance during our unit test:

class Main {
    Helper helper = new Helper();

    String methodUnderTest(int i) {
        if (i > 5) {
            return helper.getBaeldungString();
        }
        return "Hello";
    }
}

On top of that, we defined a method that accepts an Integer as a parameter and returns:

the result of the call to getBaeldunString() if the Integer is greater than 5
a constant if the Integer is less than or equal to 5

3. Real Method Called Instead of Mock

Let’s try to write a unit test for our method. We’ll use the @Mock annotation to create a mocked Helper. We’ll also invoke MockitoAnnotations.openMocks() to enable Mockito annotations. In the test method, we’ll call methodUnderTest() with the parameter 7 and check that it delegates to getBaeldungString():

class MainUnitTest {

    @Mock
    Helper helper;

    Main main = new Main();

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

    @Test
    void givenValueUpperThan5_WhenMethodUnderTest_ThenDelegatesToHelperClass() {
        main.methodUnderTest(7);
        Mockito.verify(helper)
          .getBaeldungString();
    }

}

Let’s now run our test:

Wanted but not invoked:
helper.getBaeldungString();
-> at com.baeldung.wantedbutnotinvocked.Helper.getBaeldungString(Helper.java:6)
Actually, there were zero interactions with this mock.

The problem is that we called the constructor to instantiate a Main object. Thus, the Helper instance was created by the call to new(). Consequently, we use a real Helper object instead of our mock. To fix the issue, we need to add @InjectMocks on top of our Main object creation:

@InjectMocks
Main main = new Main();

As a side note, we’ll fall back again into the same problem if we replace the mocked instance with a real object at any point of methodUnderTest():

String methodUnderTest(int i) {
    helper = new Helper();
    if (i > 5) {
        return helper.getBaeldungString();
    }
    return "Hello";
}

In a nutshell, we have two points of attention here:

The mocks should be correctly created and injected.
The mocks shouldn’t be replaced with other objects at any point.

4. Method Not Invoked

We’ll now write a new unit test. It will check that passing 3 as an argument to methodUnderTest() results in a call to getBaeldungString():

@Test
void givenValueLowerThan5_WhenMethodUnderTest_ThenDelegatesToGetBaeldungString() {
    main.methodUnderTest(3);
    Mockito.verify(helper)
      .getBaeldungString();
}

Once again, we can run the test:

Wanted but not invoked:
helper.getBaeldungString();
-> at com.baeldung.wantedbutnotinvocked.Helper.getBaeldungString(Helper.java:6)
Actually, there were zero interactions with this mock.

This time, let’s carefully read the error message. It says that we didn’t interact with the mock. Let’s now check back our method’s specification: 3 is less than 5, so methodUnderTest() returns a constant instead of delegating to getBaeldungString(). Thus, our test is contradictory to the specification.

In such a case, we have only two possible conclusions:

The specification is correct: We need to fix our test because the verification is useless.
The test is correct: There’s a bug in our code that we need to address.

5. Conclusion

In this article, we called Mockito.verify() without interacting with the mock and got an error. We pointed out that we need to inject and use the mocks properly. We also saw this error arise with an incoherent test.

The code backing this article is available on GitHub. Once you're logged in as a Baeldung Pro Member, start learning and coding on the project.

Of course, Azure Container Apps has really solid support for our ecosystem, from a number of build options, managed Java components, native metrics, dynamic logger, and quite a bit more.

To learn more about Java features on Azure Container Apps, visit the documentation page.

You can also ask questions and leave feedback on the Azure Container Apps GitHub page.

Orkes is the leading workflow orchestration platform built to enable teams to transform the way they develop, connect, and deploy applications, microservices, AI agents, and more.

Try a 14-Day Free Trial of Orkes Conductor today.

Orkes is the leading workflow orchestration platform built to enable teams to transform the way they develop, connect, and deploy applications, microservices, AI agents, and more.

Try a 14-Day Free Trial of Orkes Conductor today.