Mockito 5 Helps Mocking Constructors, Static Strategies and Closing Courses Out of the Field

Mockito, the mocking framework for Java unit exams, has launched model 5.0.0, switching the default MockMaker interface to mockito-inline with a purpose to higher assist future variations of the JDK and permits mocking of constructors, static strategies and ultimate courses out of the field. The baseline elevated from Java 8 to Java 11, as supporting each variations grew to become expensive, and managing adjustments within the JDK, such because the SecurityManager, proved troublesome.

Earlier than this launch, Mockito did not assist mocking ultimate courses out of the field, comparable to the next ultimate class which comprises one methodology:

public ultimate class Reply {

    public String retrieveAnswer() {
        return "The reply is 2";
    }
}

Within the unit take a look at a stub is used to switch the reply of the retrieveAnswer() methodology:

@Take a look at
void testMockito() {
    Reply mockedAnswer = mock();
    String reply = "42 is the Reply to the Final Query of Life, 
        the Universe, and The whole lot";
    when(mockedAnswer.retrieveAnswer()).thenReturn(reply);
    assertEquals(reply, mockedAnswer.retrieveAnswer());
}

Working the take a look at shows the next exception:

org.mockito.exceptions.base.MockitoException:
Can't mock/spy class com.app.Reply
Mockito can not mock/spy as a result of :
 - ultimate class

Mockito may mock ultimate courses by supplying the mockito-inline dependency. Nonetheless, beginning with Mockito 5.0.0, the inline MockMaker is utilized by default and helps mocking of constructors, static strategies and ultimate courses. The subclass MockMaker remains to be obtainable through the brand new mockito-subclass artifact, which is important on the Graal VM native picture because the inline mocker does not work.

The ArgumentMatcher interface permits the creation of a customized matcher which is used as methodology arguments for detailed matches. The ArgumentMatcher now helps varargs, with one argument, through the kind() methodology. For instance, with a purpose to mock the next methodology with a varargs argument:

public class Reply {
    public int depend(String... arguments) {
        return arguments.size;
    }
}

It was all the time attainable to match zero arguments or two or extra arguments:

when(mockedAnswer.depend()).thenReturn(2);
when(mockedAnswer.depend(any(), any())).thenReturn(2);

The mock may also use one any() methodology as argument:

Reply mockedAnswer = mock();
when(mockedAnswer.depend(any())).thenReturn(2);

Nonetheless, earlier than Mockito 5, the any() methodology would match any variety of arguments, as an alternative of 1 argument. The mock above would match with the next methodology invocations:

mockedAnswer.depend()
mockedAnswer.depend("one")
mockedAnswer.depend("one", "two")

Mockito 5 permits to match precisely one varargs argument with:

when(mockedAnswer.depend(any())).thenReturn(2);

Alternatively, Mockito 5 permits matching any variety of arguments:

when(mockedAnswer.depend(any(String[].class))).thenReturn(2);

Mockito 5 could also be used after including the next Maven dependency:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <model>5.0.0</model>
    <scope>take a look at</scope>
</dependency>

Alternatively, the next Gradle dependency could also be used:

testImplementation 'org.mockito:mockito-core:5.0.0'

Extra details about Mockito 5.0.0 may be discovered within the detailed explanations contained in the launch notes on GitHub.