Mockito Programming Model: Difference between revisions
(→API) |
|||
(59 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
Mockito provides a fluent API to mock Java objects. | Mockito provides a fluent API to mock Java objects. | ||
= | =Annotations= | ||
==<tt>@Mock</tt>== | |||
<syntaxhighlight lang='java'> | <syntaxhighlight lang='java'> | ||
import | import org.mockito.Mock; | ||
import org.mockito.MockitoAnnotations; | |||
import com.example.ExternalDependency; | import com.example.ExternalDependency; | ||
import static org.mockito.Mockito.when; | |||
public class SomeClassTest { | public class SomeClassTest { | ||
private AutoCloseable mocks; | |||
@Mock | |||
private ExternalDependency mockExternalDependency; | private ExternalDependency mockExternalDependency; | ||
@Before | @Before | ||
public void | public void openMocks() { | ||
mocks = MockitoAnnotations.openMocks(this); | |||
} | |||
@After | |||
public void releaseMocks() throws Exception { | |||
mocks.close(); | |||
} | } | ||
@Test | @Test | ||
public void someTest() throws Exception { | public void someTest() throws Exception { | ||
when(mockExternalDependency.someMethod()).thenReturn(...); | |||
... | ... | ||
} | } | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==<tt>@Spy</tt>== | |||
This creates a spy of a given object. It can be used instead of <code>[[#Spying_on_Real_Objects|spy(Object)]]</code>. | |||
= | ==<tt>@Captor</tt>== | ||
This simplifies the creation of [[#Verifying_Arguments_with_ArgumentCaptor|ArgumentCaptor]]. | |||
==<tt>@InjectMocks</tt>== | |||
The annotation injects mock or spy fields into tested objects automatically using '''constructor''' injection, '''setter''' injection or '''field''' injection. | |||
=API= | |||
<syntaxhighlight lang='java'> | <syntaxhighlight lang='java'> | ||
import org.mockito. | import static org.mockito.Mockito.mock; | ||
import com.example.ExternalDependency; | import com.example.ExternalDependency; | ||
public class SomeClassTest { | public class SomeClassTest { | ||
private ExternalDependency mockExternalDependency; | private ExternalDependency mockExternalDependency; | ||
@Before | @Before | ||
public void | public void setUp() { | ||
mockExternalDependency = mock(ExternalDependency.class); | |||
} | } | ||
@Test | @Test | ||
public void someTest() throws Exception { | public void someTest() throws Exception { | ||
... | ... | ||
} | } | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<font color=darkgray>How to release mocks created this way?</font> | |||
=<span id='Stub_Functionality'></span><span id='Implementing_Stub_Functionality'>Implementing Stubs= | =<span id='Stub_Functionality'></span><span id='Implementing_Stub_Functionality'>Implementing Stubs= | ||
Line 85: | Line 95: | ||
The <code>when()</code> configures the method(s) to stub, or the '''trigger action'''. The <code>then*()</code> methods specify what to do when the trigger is activated. Void methods are a [[#Void_Methods|special case]]. | The <code>when()</code> configures the method(s) to stub, or the '''trigger action'''. The <code>then*()</code> methods specify what to do when the trigger is activated. Void methods are a [[#Void_Methods|special case]]. | ||
==Void Methods== | ==Void Methods== | ||
Unit testing void methods is difficult. Conventionally, a unit test provides arguments to a method and checks the result, working with the direct output of the method. For void methods, the method presumably changes the internal state of the objects under test, to the unit test must make assertions on the indirect output of the method. A common pattern to implement this is to provide managed mocks so the void methods acts on those instead of real dependencies. | Unit testing void methods is difficult. Conventionally, a unit test provides arguments to a method and checks the result, working with the direct output of the method. For void methods, the method presumably changes the internal state of the objects under test, to the unit test must make assertions on the indirect output of the method. A common pattern to implement this is to provide managed mocks so the void methods acts on those instead of real dependencies. | ||
By default, the managed test double does nothing on void methods, so there's no need to configure anything on it. The invocation on a void method will just complete successfully. Whether the invocation was performed or not can be checked with <code>[[#Testing_Interaction_with_the_Test_Double|verify()]]</code>. | By default, the managed test double does nothing on void methods, so there's no need to configure anything on it. The invocation on a void method will just complete successfully. Whether the invocation was performed or not can be checked with <code>[[#Testing_Interaction_with_the_Test_Double|verify()]]</code>. | ||
===<tt>doAnswer()</tt> - Executing Arbitrary Logic for Void Methods=== | |||
If we need to execute arbitrary logic when a void method is invoked, use this pattern: | |||
<syntaxhighlight lang='java'> | |||
doAnswer(answer).when(mockObject).<void-method-name>(arguments); | |||
</syntaxhighlight> | |||
<syntaxhighlight lang='java'> | |||
doAnswer(new Answer() { ... }).when(mockExternalDependency).writeLine("...."); | |||
</syntaxhighlight> | |||
For more details about Answer objects, see [[#Answer|Answer]] below. | |||
If we need to simulate an exception that is thrown by a void method, use this pattern: | If we need to simulate an exception that is thrown by a void method, use this pattern: | ||
===Throwing Exceptions for Void Methods=== | ===<span id='Throwing_Exceptions_for_Void_Methods'></span><tt>toThrow()</tt> - Throwing Exceptions for Void Methods=== | ||
<syntaxhighlight lang='java'> | <syntaxhighlight lang='java'> | ||
doThrow(exception).when(mockObject).<void-method-name>(arguments); | doThrow(exception).when(mockObject).<void-method-name>(arguments); | ||
Line 99: | Line 117: | ||
doThrow(IOException.class).when(mockExternalDependency).writeLine("...."); | doThrow(IOException.class).when(mockExternalDependency).writeLine("...."); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
===<tt>doNothing()</tt>=== | |||
==<span id='Stub_Responses'></span>Stub Responses for Non-Void Methods== | ==<span id='Stub_Responses'></span>Stub Responses for Non-Void Methods== | ||
Line 109: | Line 129: | ||
* <code>thenReturn(value)</code>: return the same value every time. | * <code>thenReturn(value)</code>: return the same value every time. | ||
* <code>thenReturn(value1, value2, value3, ...)</code>: return the first value on first invocation, second value on the second invocation, etc. The equivalent is: <code>thenReturn(value1).thenReturn(value2).thenReturn(value3). ...</code> | * <code>thenReturn(value1, value2, value3, ...)</code>: return the first value on first invocation, second value on the second invocation, etc. The equivalent is: <code>thenReturn(value1).thenReturn(value2).thenReturn(value3). ...</code> | ||
⚠️ If a builder of any kind is used as argument of <code>thenReturn()</code>, the code that builds the response is executed at the time of the mock configuration, and the result computed at configuration time is returned when the stubbed method is invoked. Do not use <code>thenReturn()</code> if the result should be dynamic and evaluated at the time of invocation. Use <code>[[#thenAnswer.28.29|thenAnswer()]]</code> instead. | |||
===<tt>thenThrow()</tt>=== | ===<tt>thenThrow()</tt>=== | ||
<code>thenThrow(Throwable)</code> throws the given exception. This can be used together with JUnit feature that provides [[JUnit_Exception_Testing#.40Test_Annotation_.27expected.27_Attribute|syntactic support for tests that are supposed to check exceptions]] (<code>@Test(expected = <exception-class>)</code>). | <code>thenThrow(Throwable)</code> throws the given exception. This can be used together with JUnit feature that provides [[JUnit_Exception_Testing#.40Test_Annotation_.27expected.27_Attribute|syntactic support for tests that are supposed to check exceptions]] (<code>@Test(expected = <exception-class>)</code>). | ||
Line 122: | Line 144: | ||
====<tt>Answer</tt>==== | ====<tt>Answer</tt>==== | ||
<code>Answer</code> implementation is a callback. This is considered a somewhat controversial feature, as increases the complexity of the code. <code>[[#thenReturn()|thenReturn()]]</code> and <code>[[#thenThrow()|thenThrow()]]</code> should be used instead, if possible. | <code>Answer</code> implementation is a callback. This is considered a somewhat controversial feature, as increases the complexity of the code. <code>[[#thenReturn()|thenReturn()]]</code> and <code>[[#thenThrow()|thenThrow()]]</code> should be used instead, if possible. | ||
<syntaxhighlight lang='java'> | |||
when(mock.someMethod(anyString(), anyLong())).thenAnswer((Answer<SomeResult>) invocation -> { | |||
String arg0 = invocation.getArgument(0); | |||
long arg1 = invocation.getArgument(1); | |||
Object[] args = i.getArguments(); | |||
Object mock = i.getMock(); | |||
if ("red".equals(arg0)) { | |||
return new SomeResult("RED", arg1); | |||
} | |||
return new SomeResult(arg0, arg1); | |||
}); | |||
</syntaxhighlight> | |||
Legacy: | |||
<syntaxhighlight lang='java'> | <syntaxhighlight lang='java'> | ||
when(mock.someMethod(...)).thenAnswer(new Answer() { | when(mock.someMethod(...)).thenAnswer(new Answer() { | ||
Line 134: | Line 169: | ||
when(mock.someMethod(...)).then(new Answer() { ... }); | when(mock.someMethod(...)).then(new Answer() { ... }); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Also see executing arbitrary logic when void methods are invoked, [[#Void_Methods|above]]. | |||
==<span id='Argument_Matcher'></span>Argument Matchers== | ==<span id='Argument_Matcher'></span>Argument Matchers== | ||
The [[Software_Testing_Concepts#Test_Double|test double]] | The [[Software_Testing_Concepts#Test_Double|test double]] should be configured prior to running the test and programmed how to react when a method is invoked with specific arguments by using the <code>Mockito.when(...)</code> API. This is achieved using a mechanism called '''argument matchers'''. The actual arguments of the call are matched against a list of pre-configured options, and if there is a match, the matching entry is used to simulate the invocation response by returning a pre-set result, throw an exception, or trigger custom logic to compute the result. | ||
The default behavior in absence of any configured argument matcher is that the method returns the default value for the return type: 0 for <code>int</code>, <code>null</code> for <code>String</code>, etc. | The default behavior in absence of any configured argument matcher is that the method returns the default value for the return type: 0 for <code>int</code>, <code>null</code> for <code>String</code>, etc. Also see [[#Default_Behavior|Default Behavior]] below. | ||
The test double can be configured to issue specific responses to a method invocation based on [[#Individual_Argument_Values|individual argument values]], predefined [[#Wildcard_Matchers|wildcard matchers]] or [[#Custom_ArgumentMatcher|custom matchers]]. When using matchers, all arguments of a method must be provided by matchers. Mixing [[#Individual_Argument_Values|individual argument values]] and wildcard matchers is not allowed. The following invocation will fail: | The test double can be configured to issue specific responses to a method invocation based on [[#Individual_Argument_Values|individual argument values]], predefined [[#Wildcard_Matchers|wildcard matchers]] or [[#Custom_ArgumentMatcher|custom matchers]]. When using matchers, all arguments of a method must be provided by matchers. Mixing [[#Individual_Argument_Values|individual argument values]] and wildcard matchers is not allowed. The following invocation will fail: | ||
Line 151: | Line 187: | ||
===Wildcard Matchers=== | ===Wildcard Matchers=== | ||
Mockito wildcard marchers are static methods of the [https://github.com/mockito/mockito/blob/main/src/main/java/org/mockito/ArgumentMatchers.java org.mockito.ArgumentMatchers] class. | {{External|https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/ArgumentMatchers.html}} | ||
Mockito wildcard marchers are static methods of the [https://github.com/mockito/mockito/blob/main/src/main/java/org/mockito/ArgumentMatchers.java org.mockito.ArgumentMatchers] class. Note that the equivalent, older <code>org.mockito.Matchers</code> has been deprecated and it should not be used. | |||
<font size='-1'> | |||
{| class="wikitable" style="text-align: left;" | {| class="wikitable" style="text-align: left;" | ||
! Matcher | ! Matcher | ||
Line 166: | Line 204: | ||
| <tt>anyVararg()</tt> || | | <tt>anyVararg()</tt> || | ||
|- | |- | ||
| <tt>anyBoolean()</tt> <tt>anyByte()</tt> <tt>anyChar()</tt> <span id='anyInt'></span><tt>anyInt()</tt> <tt>anyLong()</tt> <tt>anyFloat()</tt> <tt>anyDouble()</tt> <tt>anyShort()</tt> <span id='anyString'></span><tt>anyString()</tt> || | | <tt>anyBoolean()</tt> <tt>anyByte()</tt> <tt>anyChar()</tt> <span id='anyInt'></span><tt>anyInt()</tt> <tt>anyLong()</tt> <tt>anyFloat()</tt> <tt>anyDouble()</tt> <tt>anyShort()</tt> <span id='anyString'></span><tt>[[#anyString.28.29|anyString()]]</tt> || | ||
|- | |- | ||
| <tt>anyList()</tt> <tt>anyListOf(Class<T> c)</tt> || | | <tt>anyList()</tt> <tt>anyListOf(Class<T> c)</tt> || | ||
Line 187: | Line 225: | ||
| <tt>isNull()</tt> <tt>isNull(Class<T> c)</tt> <tt>notNull()</tt> <tt>notNull(Class<T> c)</tt> <tt>isNotNull()</tt> <tt>isNotNull(Class<T> c)</tt> || | | <tt>isNull()</tt> <tt>isNull(Class<T> c)</tt> <tt>notNull()</tt> <tt>notNull(Class<T> c)</tt> <tt>isNotNull()</tt> <tt>isNotNull(Class<T> c)</tt> || | ||
|- | |- | ||
| <tt>nullable(Class<T> c)</tt> || | | <tt>[[#nullable.28Class.3CT.3E_c.29|nullable(Class<T> c)]]</tt> || | ||
|- | |- | ||
| <tt>contains(String substring)</tt> || | | <tt>contains(String substring)</tt> || | ||
Line 198: | Line 236: | ||
|- | |- | ||
|} | |} | ||
</font> | |||
====<tt>isA()</tt>==== | ====<tt>isA()</tt>==== | ||
<syntaxhighlight lang='java'> | <syntaxhighlight lang='java'> | ||
Line 215: | Line 253: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<font color=darkgray>Why is isA() needed, why not provide the class, directly?</font> | <font color=darkgray>Why is isA() needed, why not provide the class, directly?</font> | ||
====<tt>anyString()</tt>==== | |||
{{External|https://javadoc.io/static/org.mockito/mockito-core/3.11.2/org/mockito/ArgumentMatchers.html#anyString--}} | |||
⚠️ Note that since 2.1.0, <code>anyString()</code> does not match null. To match a String or <code>null</code>, use <code>nullable(String.class)</code>. | |||
====<tt>nullable(Class<T> c)</tt>==== | |||
Note that since Mockito 2.1.0, matches like <code>anyString()</code> do not match <code>null</code> values anymore. If you need a match to happen for a non-null <code>String</code> '''or''' <code>null</code>, use: | |||
<syntaxhighlight lang='java'> | |||
when(mock.someMethod(nullable(String.class))).thenReturn(...); | |||
</syntaxhighlight> | |||
===Custom <tt>ArgumentMatcher</tt>=== | ===Custom <tt>ArgumentMatcher</tt>=== | ||
Line 220: | Line 267: | ||
{{Internal|Hamcrest|Hamcrest}} | {{Internal|Hamcrest|Hamcrest}} | ||
=<span id='Implementing_Spys'></span>Implementing Spies= | ==Default Behavior== | ||
Non-stubbed methods for a mock objects, as well as invocations for which there's no argument match, return default values: <code>null</code> for an Object, 0 for an integer, <code>false</code> for a boolean. | |||
This behavior can be changed by configuring Mockito with the following options: | |||
* RETURNS_DEFAULTS. The default behavior. | |||
* RETURNS_SMART_NULLS. Return stubs that act like nulls, in that they throw exceptions if a method is attempted to be called on them. The exceptions are more useful that the normal <code>NullPointerException</code> behavior. | |||
* RETURNS_MOCKS. Return mocks for objects and default values for primitives. | |||
* RETURNS_DEEP_STUBS. | |||
* CALL_REAL_METHODS. | |||
==Determining whether a Test Double is a Mock== | |||
<syntaxhighlight lang='java'> | |||
import static org.mockito.Mockito.mockingDetails; | |||
mockingDetails(mockObject).isMock(); | |||
</syntaxhighlight> | |||
=<span id='Implementing_Spys'></span><span id='Implementing_Spies'></span>Implementing Spies= | |||
==Testing Interaction with the Test Double== | ==Testing Interaction with the Test Double== | ||
===Number of Invocations=== | ===Number of Invocations=== | ||
{{External|https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#exact_verification}} | {{External|https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#exact_verification}} | ||
Many times during testing it is useful to know if our mocked external dependency was called into with a specific method, or any method, how many times per method, and so on. Mockito exposes API for this in form of the <code>Mockito.verify(...)</code> set of methods. The mock object should be declared and configured as described in the [[#Annotations|Annotations]] section. Then the number of invocations of certain methods, or whether the methods have been invoked at all, can be tested with: | Many times during testing it is useful to know if our mocked external dependency was called into with a specific method, or any method, how many times per method, and so on. Mockito exposes API for this in form of the <code>Mockito.verify(...)</code> set of methods. The mock object should be declared and configured as described in the [[#Annotations|Annotations]] section. Then the number of invocations of certain methods, or whether the methods have been invoked at all, can be tested with: | ||
<syntaxhighlight lang='java'> | <syntaxhighlight lang='java'> | ||
Line 248: | Line 309: | ||
verify(mock, only()).someMethod("some argument"); | verify(mock, only()).someMethod("some argument"); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
===Mock-wide Interactions=== | ===Mock-wide Interactions=== | ||
{{External|https://javadoc.io/static/org.mockito/mockito-core/3.11.2/org/mockito/Mockito.html#never_verification}} | {{External|https://javadoc.io/static/org.mockito/mockito-core/3.11.2/org/mockito/Mockito.html#never_verification}} | ||
Line 254: | Line 314: | ||
verifyZeroInteractions(mockOne, mockTwo); | verifyZeroInteractions(mockOne, mockTwo); | ||
verifyNoMoreInteractions(mock); | verifyNoMoreInteractions(mock); | ||
</syntaxhighlight> | |||
===Invocation Order=== | |||
<font color=darkgray>TODO Mockito Essentials "Verifying an invocation order".</font> | |||
===Verifying Arguments with <tt>ArgumentCaptor</tt>=== | |||
<font color=darkgray>TODO Mockito Essentials "Verifying arguments using ArgumentCaptor". | |||
Generic collection arguments. | |||
Variable arguments and arrays. | |||
Also see [[#.40Captor|@Captor]] | |||
</font> | |||
==Spying on Real Objects== | |||
<font color=darkgray>TODO Mockito Essentials "Spying Objects". | |||
<code>spy(Object)</code>. Also see [[#.40Spy|@Spy]] | |||
</font> | |||
==Determining whether a Test Double is a Spy== | |||
<syntaxhighlight lang='java'> | |||
import static org.mockito.Mockito.mockingDetails; | |||
mockingDetails(testDoubleObject).isSpy(); | |||
</syntaxhighlight> | </syntaxhighlight> | ||
=Resetting Mock Objects= | =Resetting Mock Objects= | ||
A mock object can be reset via API. | A mock object can be reset via API. | ||
<syntaxhighlight lang='java'> | |||
import static org.mockito.Mockito.reset; | |||
... | |||
reset(mockObject); | |||
</syntaxhighlight> | |||
=Troubleshooting= | |||
* No configured invocation matches the current invocation. The configured invocation is declared with an int argument, and the invocation is made with a long. |
Latest revision as of 00:33, 3 September 2021
Internal
Overview
Mockito provides a fluent API to mock Java objects.
Annotations
@Mock
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import com.example.ExternalDependency;
import static org.mockito.Mockito.when;
public class SomeClassTest {
private AutoCloseable mocks;
@Mock
private ExternalDependency mockExternalDependency;
@Before
public void openMocks() {
mocks = MockitoAnnotations.openMocks(this);
}
@After
public void releaseMocks() throws Exception {
mocks.close();
}
@Test
public void someTest() throws Exception {
when(mockExternalDependency.someMethod()).thenReturn(...);
...
}
}
@Spy
This creates a spy of a given object. It can be used instead of spy(Object)
.
@Captor
This simplifies the creation of ArgumentCaptor.
@InjectMocks
The annotation injects mock or spy fields into tested objects automatically using constructor injection, setter injection or field injection.
API
import static org.mockito.Mockito.mock;
import com.example.ExternalDependency;
public class SomeClassTest {
private ExternalDependency mockExternalDependency;
@Before
public void setUp() {
mockExternalDependency = mock(ExternalDependency.class);
}
@Test
public void someTest() throws Exception {
...
}
}
How to release mocks created this way?
Implementing Stubs
A stub returns synthetic responses or throws exceptions when its methods are invoked. Mockito supports stubbing and by returning a given value when a specific method of the managed test double is called. Mockito implements the stub functionality with Mockito.when(<method>).then*(...)
pattern - using this API pattern is often referred to as "setting the expectations". The synthetic response is selected based on the arguments of the call, using the arguments values themselves or argument matchers:
public class ExternalDependency {
public String someMethod() {
...
}
}
import static org.mockito.Mockito.when;
public class SomeClassTest {
@Mock
private ExternalDependency mockExternalDependency;
@Test
public void someTest() throws Exception {
when(mockExternalDependency.someMethod()).thenReturn("some synthetic result");
...
}
}
The when()
configures the method(s) to stub, or the trigger action. The then*()
methods specify what to do when the trigger is activated. Void methods are a special case.
Void Methods
Unit testing void methods is difficult. Conventionally, a unit test provides arguments to a method and checks the result, working with the direct output of the method. For void methods, the method presumably changes the internal state of the objects under test, to the unit test must make assertions on the indirect output of the method. A common pattern to implement this is to provide managed mocks so the void methods acts on those instead of real dependencies.
By default, the managed test double does nothing on void methods, so there's no need to configure anything on it. The invocation on a void method will just complete successfully. Whether the invocation was performed or not can be checked with verify()
.
doAnswer() - Executing Arbitrary Logic for Void Methods
If we need to execute arbitrary logic when a void method is invoked, use this pattern:
doAnswer(answer).when(mockObject).<void-method-name>(arguments);
doAnswer(new Answer() { ... }).when(mockExternalDependency).writeLine("....");
For more details about Answer objects, see Answer below.
If we need to simulate an exception that is thrown by a void method, use this pattern:
toThrow() - Throwing Exceptions for Void Methods
doThrow(exception).when(mockObject).<void-method-name>(arguments);
doThrow(IOException.class).when(mockExternalDependency).writeLine("....");
doNothing()
Stub Responses for Non-Void Methods
The common pattern on non-void methods is:
when(mockExternalDependency.<some-method>(...)).then*(...);
thenReturn()
thenReturn(...)
returns the given value. It has several variants:
thenReturn(value)
: return the same value every time.thenReturn(value1, value2, value3, ...)
: return the first value on first invocation, second value on the second invocation, etc. The equivalent is:thenReturn(value1).thenReturn(value2).thenReturn(value3). ...
⚠️ If a builder of any kind is used as argument of thenReturn()
, the code that builds the response is executed at the time of the mock configuration, and the result computed at configuration time is returned when the stubbed method is invoked. Do not use thenReturn()
if the result should be dynamic and evaluated at the time of invocation. Use thenAnswer()
instead.
thenThrow()
thenThrow(Throwable)
throws the given exception. This can be used together with JUnit feature that provides syntactic support for tests that are supposed to check exceptions (@Test(expected = <exception-class>)
).
when(mockExternalDependency.someMethod()).thenThrow(IOException.class);
There is alternative syntax for throwing exceptions on void methods.
thenCallRealMethod()
thenCallRealMethod()
delegates the invocation to the real external dependency.
thenAnswer()
thenAnswer(Answer answer)
executes custom logic and compute a value to return. This turns the stub object into a fake. It uses Answers:
Answer
Answer
implementation is a callback. This is considered a somewhat controversial feature, as increases the complexity of the code. thenReturn()
and thenThrow()
should be used instead, if possible.
when(mock.someMethod(anyString(), anyLong())).thenAnswer((Answer<SomeResult>) invocation -> {
String arg0 = invocation.getArgument(0);
long arg1 = invocation.getArgument(1);
Object[] args = i.getArguments();
Object mock = i.getMock();
if ("red".equals(arg0)) {
return new SomeResult("RED", arg1);
}
return new SomeResult(arg0, arg1);
});
Legacy:
when(mock.someMethod(...)).thenAnswer(new Answer() {
public Object answer(InvocationOnMock i) {
Object[] args = i.getArguments();
Object mock = i.getMock();
return "called with arguments: " + Arrays.toString(args);
}
});
when(mock.someMethod(...)).then(new Answer() { ... });
Also see executing arbitrary logic when void methods are invoked, above.
Argument Matchers
The test double should be configured prior to running the test and programmed how to react when a method is invoked with specific arguments by using the Mockito.when(...)
API. This is achieved using a mechanism called argument matchers. The actual arguments of the call are matched against a list of pre-configured options, and if there is a match, the matching entry is used to simulate the invocation response by returning a pre-set result, throw an exception, or trigger custom logic to compute the result.
The default behavior in absence of any configured argument matcher is that the method returns the default value for the return type: 0 for int
, null
for String
, etc. Also see Default Behavior below.
The test double can be configured to issue specific responses to a method invocation based on individual argument values, predefined wildcard matchers or custom matchers. When using matchers, all arguments of a method must be provided by matchers. Mixing individual argument values and wildcard matchers is not allowed. The following invocation will fail:
verify(mock).someMethod(1, anyString(), "some string");
However, this situation can be easily worked around by using the eq(...)
in lieu of an individual value:
verify(mock).someMethod(eq(1), anyString(), eq("some string"));
Individual Argument Values
Wildcard Matchers
Mockito wildcard marchers are static methods of the org.mockito.ArgumentMatchers class. Note that the equivalent, older org.mockito.Matchers
has been deprecated and it should not be used.
Matcher | Notes |
---|---|
any() | |
anyObject() | |
any(Class<T> c) | |
isA(Class<T> c) | Example below |
anyVararg() | |
anyBoolean() anyByte() anyChar() anyInt() anyLong() anyFloat() anyDouble() anyShort() anyString() | |
anyList() anyListOf(Class<T> c) | |
anySet() anySetOf(Class<T> c) | |
anyMap() anyMapOf(Class<K> keyC, Class<V> valueC) | |
anyCollection() anyCollectionOf(Class<T> c) | |
anyIterable() anyIterableOf(Class<T> c) | |
eq(T value)
eq(boolean value) eq(byte value) eq(char value) | |
refEq(T value, String... excludeFields) | |
same(T value) | |
isNull() isNull(Class<T> c) notNull() notNull(Class<T> c) isNotNull() isNotNull(Class<T> c) | |
nullable(Class<T> c) | |
contains(String substring) | |
matches(String regex) matches(String regex) | |
endsWith(String suffix) startsWith(String prefix) | |
argThat(ArgumentMatcher<T> m) charThat(ArgumentMatcher<Character> m) booleanThat(ArgumentMatcher<Boolean> m) byteThat(ArgumentMatcher<Byte> m) shortThat(ArgumentMatcher<Short> m) intThat(ArgumentMatcher<Integer> m) longThat(ArgumentMatcher<Long> m) floatThat(ArgumentMatcher<Float> m) doubleThat(ArgumentMatcher<Double> m) |
isA()
public class ExternalDependency {
public String someMethodWithArg(String s) {
...
}
}
import static org.mockito.ArgumentMatchers.isA;
import static org.mockito.Mockito.when;
...
when(mockExternalDependency.someMethodWithArg(isA(String.class))).thenReturn(...);
Why is isA() needed, why not provide the class, directly?
anyString()
⚠️ Note that since 2.1.0, anyString()
does not match null. To match a String or null
, use nullable(String.class)
.
nullable(Class<T> c)
Note that since Mockito 2.1.0, matches like anyString()
do not match null
values anymore. If you need a match to happen for a non-null String
or null
, use:
when(mock.someMethod(nullable(String.class))).thenReturn(...);
Custom ArgumentMatcher
TODO. "Working with a custom ArgumentMatcher class" section in Mockito Essentials.
Default Behavior
Non-stubbed methods for a mock objects, as well as invocations for which there's no argument match, return default values: null
for an Object, 0 for an integer, false
for a boolean.
This behavior can be changed by configuring Mockito with the following options:
- RETURNS_DEFAULTS. The default behavior.
- RETURNS_SMART_NULLS. Return stubs that act like nulls, in that they throw exceptions if a method is attempted to be called on them. The exceptions are more useful that the normal
NullPointerException
behavior. - RETURNS_MOCKS. Return mocks for objects and default values for primitives.
- RETURNS_DEEP_STUBS.
- CALL_REAL_METHODS.
Determining whether a Test Double is a Mock
import static org.mockito.Mockito.mockingDetails;
mockingDetails(mockObject).isMock();
Implementing Spies
Testing Interaction with the Test Double
Number of Invocations
Many times during testing it is useful to know if our mocked external dependency was called into with a specific method, or any method, how many times per method, and so on. Mockito exposes API for this in form of the Mockito.verify(...)
set of methods. The mock object should be declared and configured as described in the Annotations section. Then the number of invocations of certain methods, or whether the methods have been invoked at all, can be tested with:
import static org.mockito.Mockito.verify;
...
verify(mock).someMethod("some argument");
This invocation succeeds if the method someMethod()
was invoked with the argument "some argument"
once and only once. The invocation is equivalent with:
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.times;
...
verify(mock, times(1)).someMethod("some argument");
Other options:
verify(mock, never()).someMethod("some argument");
verify(mock, atMostOnce()).someMethod("some argument");
verify(mock, atLeastOnce()).someMethod("some argument");
verify(mock, atLeast(2)).someMethod("some argument");
verify(mock, atMost(5)).someMethod("some argument");
verify(mock, only()).someMethod("some argument");
Mock-wide Interactions
verifyZeroInteractions(mockOne, mockTwo);
verifyNoMoreInteractions(mock);
Invocation Order
TODO Mockito Essentials "Verifying an invocation order".
Verifying Arguments with ArgumentCaptor
TODO Mockito Essentials "Verifying arguments using ArgumentCaptor".
Generic collection arguments.
Variable arguments and arrays.
Also see @Captor
Spying on Real Objects
TODO Mockito Essentials "Spying Objects".
spy(Object)
. Also see @Spy
Determining whether a Test Double is a Spy
import static org.mockito.Mockito.mockingDetails;
mockingDetails(testDoubleObject).isSpy();
Resetting Mock Objects
A mock object can be reset via API.
import static org.mockito.Mockito.reset;
...
reset(mockObject);
Troubleshooting
- No configured invocation matches the current invocation. The configured invocation is declared with an int argument, and the invocation is made with a long.