Mockito's Mock Methods

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 illustrate the various uses of the standard static mock methods of the Mockito API.

As in other articles focused on the Mockito framework (like Mockito Verify or Mockito When/Then), the MyList class shown below will be used as the collaborator to be mocked in test cases:

public class MyList extends AbstractList<String> {

    @Override
    public String get(int index) {
        return null;
    }

    @Override
    public int size() {
        return 1;
    }
}

2. Simple Mocking

The simplest overloaded variant of the mock method is the one with a single parameter for the class to be mocked:

public static <T> T mock(Class<T> classToMock)

We’ll use this method to mock a class and set an expectation:

MyList listMock = mock(MyList.class);
when(listMock.add(anyString())).thenReturn(false);

Then we’ll execute a method on the mock:

boolean added = listMock.add(randomAlphabetic(6));

The following code confirms that we invoked the add method on the mock. The invocation returns a value that matches the expectation we set before:

verify(listMock).add(anyString());
assertThat(added).isFalse();

3. Mocking With Mock’s Name

In this section, we’ll cover another variant of the mock method, which is provided with an argument specifying the name of the mock:

public static <T> T mock(Class<T> classToMock, String name)

Generally speaking, the name of a mock has nothing to do with the working code. However, it may be helpful in debugging, as we use the mock’s name to track down verification errors.

To ensure the exception message thrown from an unsuccessful verification includes the provided name of a mock, we’ll use assertThatThrownBy.
In the following code, we’ll create a mock for the MyList class and name it myMock:

MyList listMock = mock(MyList.class, "myMock");

Then we’ll set an expectation on a method of the mock and execute it:

when(listMock.add(anyString())).thenReturn(false);
listMock.add(randomAlphabetic(6));

Next, we’ll call the verification inside the assertThatThrownBy and verify the instance of the exception thrown:

assertThatThrownBy(() -> verify(listMock, times(2)).add(anyString()))
    .isInstanceOf(TooFewActualInvocations.class)

Further, we can also verify the exception’s message that it should contain the information about the mock:

assertThatThrownBy(() -> verify(listMock, times(2)).add(anyString()))
    .isInstanceOf(TooFewActualInvocations.class)
    .hasMessageContaining("myMock.add");

Here’s the thrown exception’s message:

org.mockito.exceptions.verification.TooLittleActualInvocations:
myMock.add(<any>);
Wanted 2 times:
at com.baeldung.mockito.MockitoMockTest
  .whenUsingMockWithName_thenCorrect(MockitoMockTest.java:...)
but was 1 time:
at com.baeldung.mockito.MockitoMockTest
  .whenUsingMockWithName_thenCorrect(MockitoMockTest.java:...)

As we can see, the exception message includes the mock’s name, which will be useful for finding the failure point in case of an unsuccessful verification.

4. Mocking With Answer

Here we’ll demonstrate the use of a mock variant in which we’ll configure the strategy for the mock’s answers to interaction at creation time. This mock method’s signature in the Mockito documentation looks like the following:

public static <T> T mock(Class<T> classToMock, Answer defaultAnswer)

Let’s start with the definition of an implementation of the Answer interface:

class CustomAnswer implements Answer<Boolean> {

    @Override
    public Boolean answer(InvocationOnMock invocation) throws Throwable {
        return false;
    }
}

We’ll use the CustomAnswer class above for the generation of a mock:

MyList listMock = mock(MyList.class, new CustomAnswer());

If we don’t set an expectation on a method, the default answer, configured by the CustomAnswer type, will come into play. In order to prove this, we’ll skip over the expectation setting step and jump to the method execution:

boolean added = listMock.add(randomAlphabetic(6));

The following verification and assertion confirm that the mock method with an Answer argument worked as expected:

verify(listMock).add(anyString());
assertThat(added).isFalse();

5. Mocking With MockSettings

The final mock method we’ll cover in this article is the variant with a parameter of the MockSettings type. We use this overloaded method to provide a non-standard mock.

There are several custom settings supported by methods of the MockSettings interface, such as registering a listener for method invocations on the current mock with invocationListeners, configuring serialization with serializable, specifying the instance to spy on with spiedInstance, configuring Mockito to attempt to use a constructor when instantiating a mock with useConstructor, etc.

For convenience, we’ll reuse the CustomAnswer class introduced in the previous section to create a MockSettings implementation that defines a default answer.

A MockSettings object is instantiated by a factory method:

MockSettings customSettings = withSettings().defaultAnswer(new CustomAnswer());

We’ll use that setting object in the creation of a new mock:

MyList listMock = mock(MyList.class, customSettings);

Similar to the preceding section, we’ll invoke the add method of a MyList instance, and verify that the mock method with a MockSettings argument works as expected:

boolean added = listMock.add(randomAlphabetic(6));

verify(listMock).add(anyString());
assertThat(added).isFalse();

6. Conclusion

In this article, we covered the mock method of Mockito in detail.

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.