org.mockito
Class Mockito

This javadoc content is also available on the http://mockito.org web page.
All documentation is kept in javadocs because it guarantees consistency between what's on the web and what's in the source code.
Also, it makes possible to access documentation straight from the IDE even if you work offline.

Stubbing can be overridden: for example common stubbing can go to
fixture setup but the test methods can override it.
Please note that overridding stubbing is a potential code smell that points out too much stubbing

Once stubbed, the method will always return stubbed value regardless
of how many times it is called.

Last stubbing is more important - when you stubbed the same method with
the same arguments many times.
Other words: the order of stubbing matters but it is only meaningful rarely,
e.g. when stubbing exactly the same method calls or sometimes when argument matchers are used, etc.

For information solely on custom argument matchers check out javadoc for ArgumentMatcher class.

Be reasonable with using complicated argument matching.
The natural matching style using equals() with occasional anyX() matchers tend to give clean & simple tests.
Sometimes it's just better to refactor the code to allow equals() matching or even implement equals() method to help out with testing.

If you are using argument matchers, all arguments have to be provided
by matchers.

E.g: (example shows verification but the same applies to stubbing):

verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));
//above is correct - eq() is also an argument matcher
verify(mock).someMethod(anyInt(), anyString(), "third argument");
//above is incorrect - exception will be thrown because third argument is given without an argument matcher.

Matcher methods like anyObject(), eq()do not return matchers.
Internally, they record a matcher on a stack and return a dummy value (usually null).
This implementation is due static type safety imposed by java compiler.
The consequence is that you cannot use anyObject(), eq() methods outside of verified/stubbed method.

// A. Single mock whose methods must be invoked in a particular order
List singleMock = mock(List.class);
//using a single mock
singleMock.add("was added first");
singleMock.add("was added second");
//create an inOrder verifier for a single mock
InOrder inOrder = inOrder(singleMock);
//following will make sure that add is first called with "was added first, then with "was added second"
inOrder.verify(singleMock).add("was added first");
inOrder.verify(singleMock).add("was added second");
// B. Multiple mocks that must be used in a particular order
List firstMock = mock(List.class);
List secondMock = mock(List.class);
//using mocks
firstMock.add("was called first");
secondMock.add("was called second");
//create inOrder object passing any mocks that need to be verified in order
InOrder inOrder = inOrder(firstMock, secondMock);
//following will make sure that firstMock was called before secondMock
inOrder.verify(firstMock).add("was called first");
inOrder.verify(secondMock).add("was called second");
// Oh, and A + B can be mixed together at will

Verification in order is flexible - you don't have to verify all
interactions one-by-one but only those that you are interested in
testing in order.

Also, you can create InOrder object passing only mocks that are relevant for
in-order verification.

//using mocks - only mockOne is interacted
mockOne.add("one");
//ordinary verification
verify(mockOne).add("one");
//verify that method was never called on a mock
verify(mockOne, never()).add("two");
//verify that other mocks were not interacted
verifyZeroInteractions(mockTwo, mockThree);

A word of warning:
Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method.
verifyNoMoreInteractions() is not recommended to use in every test method.
verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant.
Abusing it leads to overspecified, less maintainable tests. You can find further reading
here.

See also never() - it is more explicit and
communicates the intent well.

Sometimes we need to stub with different return value/exception for the same
method call. Typical use case could be mocking iterators.
Original version of Mockito did not have this feature to promote simple mocking.
For example, instead of iterators one could use Iterable or simply
collections. Those offer natural ways of stubbing (e.g. using real
collections). In rare scenarios stubbing consecutive calls could be useful,
though:

Yet another controversial feature which was not included in Mockito
originally. We recommend using simple stubbing with thenReturn() or
thenThrow() only. Those two should be just enough to test/test-drive
any clean & simple code.

You can create spies of real objects. When you use the spy then the real methods are called
(unless a method was stubbed).

Real spies should be used carefully and occasionally, for example when dealing with legacy code.

Spying on real objects can be associated with "partial mocking" concept.
Before the release 1.8, Mockito spies were not real partial mocks.
The reason was we thought partial mock is a code smell.
At some point we found legitimate use cases for partial mocks
(3rd party interfaces, interim refactoring of legacy code, the full article is here)

Important gotcha on spying real objects!

Sometimes it's impossible or impractical to use when(Object) for stubbing spies.
Therefore when using spies please consider doReturn|Answer|Throw() family of
methods for stubbing. Example:

List list = new LinkedList();
List spy = spy(list);
//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");
//You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);

Mockito *does not* delegate calls to the passed real instance, instead it actually creates a copy of it.
So if you keep the real instance and interact with it, don't expect the spied to be aware of those interaction
and their effect on real instance state.
The corollary is that when an *unstubbed* method is called *on the spy* but *not on the real instance*,
you won't see any effects on the real instance.

Watch out for final methods.
Mockito doesn't mock final methods so the bottom line is: when you spy on real objects + you try to stub a final method = trouble.
Also you won't be able to verify those method as well.

You can create a mock with specified strategy for its return values.
It's quite advanced feature and typically you don't need it to write decent tests.
However, it can be helpful for working with legacy systems.

It is the default answer so it will be used only when you don't stub the method call.

Mockito verifies argument values in natural java style: by using an equals() method.
This is also the recommended way of matching arguments because it makes tests clean & simple.
In some situations though, it is helpful to assert on certain arguments after the actual verification.
For example:

Warning: it is recommended to use ArgumentCaptor with verification but not with stubbing.
Using ArgumentCaptor with stubbing may decrease test readability because captor is created outside of assert (aka verify or 'then') block.
Also it may reduce defect localization because if stubbed method was not called then no argument is captured.

In a way ArgumentCaptor is related to custom argument matchers (see javadoc for ArgumentMatcher class).
Both techniques can be used for making sure certain arguments where passed to mocks.
However, ArgumentCaptor may be a better fit if:

custom argument matcher is not likely to be reused

you just need it to assert on argument values to complete verification

Custom argument matchers via ArgumentMatcher are usually better for stubbing.

Finally, after many internal debates & discussions on the mailing list, partial mock support was added to Mockito.
Previously we considered partial mocks as code smells. However, we found a legitimate use case for partial mocks - more reading:
here

Before release 1.8spy() was not producing real partial mocks and it was confusing for some users.
Read more about spying: here or in javadoc for spy(Object) method.

As usual you are going to read the partial mock warning:
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
How does partial mock fit into this paradigm? Well, it just doesn't...
Partial mock usually means that the complexity has been moved to a different method on the same object.
In most cases, this is not the way you want to design your application.

However, there are rare cases when partial mocks come handy:
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
However, I wouldn't use partial mocks for new, test-driven & well-designed code.

Smart Mockito users hardly use this feature because they know it could be a sign of poor tests.
Normally, you don't need to reset your mocks, just create new mocks for each test method.

Instead of reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests.
First potential code smell is reset() in the middle of the test method. This probably means you're testing too much.
Follow the whisper of your test methods: "Please keep us small & focused on single behavior".
There are several threads about it on mockito mailing list.

The only reason we added reset() method is to
make it possible to work with container-injected mocks.
See issue 55 (here)
or FAQ (here).

Don't harm yourself.reset() in the middle of the test method is a code smell (you're probably testing too much).

Behavior Driven Development style of writing tests uses //given //when //then comments as fundamental parts of your test methods.
This is exactly how we write our tests and we warmly encourage you to do so!

The problem is that current stubbing api with canonical role of when word does not integrate nicely with //given //when //then comments.
It's because stubbing belongs to given component of the test and not to the when component of the test.
Hence BDDMockito class introduces an alias so that you stub method calls with BDDMockito.given(Object) method.
Now it really nicely integrates with the given component of a BDD style test!

Mocks can be made serializable. With this feature you can use a mock in a place that requires dependencies to be serializable.

WARNING: This should be rarely used in unit testing.

The behaviour was implemented for a specific use case of a BDD spec that had an unreliable external dependency. This
was in a web environment and the objects from the external dependency were being serialized to pass between layers.

Note that @InjectMocks can only be used in combination with the @Spy annotation, it means
that Mockito will inject mocks in a partial mock under testing. As a remainder, please read point 16 about partial mocks.

Allows verifying with timeout. It causes a verify to wait for a specified period of time for a desired
interaction rather than fails immediately if had not already happened. May be useful for testing in concurrent
conditions.

It feels this feature should be used rarely - figure out a better way of testing your multi-threaded system.

Not yet implemented to work with InOrder verification.

Examples:

//passes when someMethod() is called within given time span
verify(mock, timeout(100)).someMethod();
//above is an alias to:
verify(mock, timeout(100).times(1)).someMethod();
//passes when someMethod() is called *exactly* 2 times within given time span
verify(mock, timeout(100).times(2)).someMethod();
//passes when someMethod() is called *at least* 2 times within given time span
verify(mock, timeout(100).atLeast(2)).someMethod();
//verifies someMethod() within given time span using given verification mode
//useful only if you have your own custom verification modes.
verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();

Mockito will now allow you to create mocks when stubbing.
Basically, it allows to create a stub in one line of code.
This can be helpful to keep test code clean.
For example, some boring stub can be created & stubbed at field initialization in a test:

Mockito will now allow to ignore stubbing for the sake of verification.
Sometimes useful when coupled with verifyNoMoreInteractions() or verification inOrder().
Helps avoiding redundant verification of stubbed calls - typically we're not interested in verifying stubs.

Warning, ignoreStubs() might lead to overuse of verifyNoMoreInteractions(ignoreStubs(...));
Bear in mind that Mockito does not recommend bombarding every test with verifyNoMoreInteractions()
for the reasons outlined in javadoc for verifyNoMoreInteractions(Object...)

Both the MockingDetails.isMock() and MockingDetails.isSpy() methods return boolean.
As a spy is just a different kind of mock, isMock() returns true if the object is a spy.
In future Mockito versions MockingDetails may grow and provide other useful information about the mock,
e.g. invocations, stubbing info, etc.

Useful for spies or partial mocks of objects that are difficult to mock or spy using the usual spy API.
Possible use cases:

Final classes but with an interface

Already custom proxied object

Special objects with a finalize method, i.e. to avoid executing it 2 times

The difference with the regular spy:

The regular spy (spy(Object)) contains all state from the spied instance
and the methods are invoked on the spy. The spied instance is only used at mock creation to copy the state from.
If you call a method on a regular spy and it internally calls other methods on this spy, those calls are remembered
for verifications, and they can be effectively stubbed.

The mock that delegates simply delegates all methods to the delegate.
The delegate is used all the time as methods are delegated onto it.
If you call a method on a mock that delegates and it internally calls other methods on this mock,
those calls are not remembered for verifications, stubbing does not have effect on them, too.
Mock that delegates is less powerful than the regular spy but it is useful when the regular spy cannot be created.

Driven by requirements and patches from Google Android guys Mockito now offers an extension point
that allows replacing the proxy generation engine. By default, Mockito uses cglib to create dynamic proxies.

The extension point is for advanced users that want to extend Mockito. For example, it is now possible
to use Mockito for Android testing with a help of dexmaker.

For more details, motivations and examples please refer to
the docs for MockMaker.

RETURNS_SMART_NULLS

Answer can be used to define the return values of unstubbed invocations.

This implementation can be helpful when working with legacy code.
Unstubbed methods often return null. If your code uses the object returned by an unstubbed call you get a NullPointerException.
This implementation of Answer returns SmartNull instead of null.
SmartNull gives nicer exception message than NPE because it points out the line where unstubbed method was called. You just click on the stack trace.

ReturnsSmartNulls first tries to return ordinary return values (see ReturnsMoreEmptyValues)
then it tries to return SmartNull. If the return type is final then plain null is returned.

ReturnsSmartNulls will be probably the default return values strategy in Mockito 2.0.

WARNING:
This feature should rarely be required for regular clean code! Leave it for legacy code.
Mocking a mock to return a mock, to return a mock, (...), to return something meaningful
hints at violation of Law of Demeter or mocking a value object (a well known anti-pattern).

Good quote I've seen one day on the web: every time a mock returns a mock a fairy dies.

Please note that this answer will return existing mocks that matches the stub. This
behavior is ok with deep stubs and allows verification to work on the last mock of the chain.

CALLS_REAL_METHODS

Answer can be used to define the return values of unstubbed invocations.

This implementation can be helpful when working with legacy code.
When this implementation is used, unstubbed methods will delegate to the real implementation.
This is a way to create a partial mock object that calls real methods by default.

As usual you are going to read the partial mock warning:
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
How does partial mock fit into this paradigm? Well, it just doesn't...
Partial mock usually means that the complexity has been moved to a different method on the same object.
In most cases, this is not the way you want to design your application.

However, there are rare cases when partial mocks come handy:
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
However, I wouldn't use partial mocks for new, test-driven & well-designed code.

mock

Specifies mock name. Naming mocks can be helpful for debugging - the name is used in all verification errors.

Beware that naming mocks is not a solution for complex code which uses too many mocks or collaborators.
If you have too many mocks then refactor the code so that it's easy to test/debug without necessity of naming mocks.

If you use @Mock annotation then you've got naming mocks for free!@Mock uses field name as mock name. Read more.

mockingDetails

Returns a MockingDetails instance that enables inspecting a particular object for Mockito related information.
Can be used to find out if given object is a Mockito mock
or to find out if a given mock is a spy or mock.

In future Mockito versions MockingDetails may grow and provide other useful information about the mock,
e.g. invocations, stubbing info, etc.

Why it is deprecated? ReturnValues is being replaced by Answer
for better consistency & interoperability of the framework.
Answer interface has been in Mockito for a while and it has the same responsibility as ReturnValues.
There's no point in mainting exactly the same interfaces.

Creates mock with a specified strategy for its return values.
It's quite advanced feature and typically you don't need it to write decent tests.
However it can be helpful when working with legacy systems.

Obviously return values are used only when you don't stub the method call.

mock

Creates mock with a specified strategy for its answers to interactions.
It's quite advanced feature and typically you don't need it to write decent tests.
However it can be helpful when working with legacy systems.

It is the default answer so it will be used only when you don't stub the method call.

Use it carefully and occasionally. What might be reason your test needs non-standard mocks?
Is the code under test so complicated that it requires non-standard mocks?
Wouldn't you prefer to refactor the code under test so it is testable in a simple way?

spy

Creates a spy of the real object. The spy calls real methods unless they are stubbed.

Real spies should be used carefully and occasionally, for example when dealing with legacy code.

As usual you are going to read the partial mock warning:
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
How does partial mock fit into this paradigm? Well, it just doesn't...
Partial mock usually means that the complexity has been moved to a different method on the same object.
In most cases, this is not the way you want to design your application.

However, there are rare cases when partial mocks come handy:
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
However, I wouldn't use partial mocks for new, test-driven & well-designed code.

Important gotcha on spying real objects!

Sometimes it's impossible or impractical to use when(Object) for stubbing spies.
Therefore for spies it is recommended to always use doReturn|Answer|Throw()|CallRealMethod
family of methods for stubbing. Example:

List list = new LinkedList();
List spy = spy(list);
//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");
//You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);

Mockito *does not* delegate calls to the passed real instance, instead it actually creates a copy of it.
So if you keep the real instance and interact with it, don't expect the spied to be aware of those interaction
and their effect on real instance state.
The corollary is that when an *unstubbed* method is called *on the spy* but *not on the real instance*,
you won't see any effects on the real instance.

Watch out for final methods.
Mockito doesn't mock final methods so the bottom line is: when you spy on real objects + you try to stub a final method = trouble.
Also you won't be able to verify those method as well.

Stubbing can be overridden: for example common stubbing can go to fixture
setup but the test methods can override it.
Please note that overridding stubbing is a potential code smell that points out too much stubbing.

Once stubbed, the method will always return stubbed value regardless
of how many times it is called.

Last stubbing is more important - when you stubbed the same method with
the same arguments many times.

Although it is possible to verify a stubbed invocation, usually it's just redundant.
Let's say you've stubbed foo.bar().
If your code cares what foo.bar() returns then something else breaks(often before even verify() gets executed).
If your code doesn't care what get(0) returns then it should not be stubbed.
Not convinced? See here.

Stubbing can be overridden: for example common stubbing can go to fixture
setup but the test methods can override it.
Please note that overridding stubbing is a potential code smell that points out too much stubbing.

Once stubbed, the method will always return stubbed value regardless
of how many times it is called.

Last stubbing is more important - when you stubbed the same method with
the same arguments many times.

Although it is possible to verify a stubbed invocation, usually it's just redundant.
Let's say you've stubbed foo.bar().
If your code cares what foo.bar() returns then something else breaks(often before even verify() gets executed).
If your code doesn't care what get(0) returns then it should not be stubbed.
Not convinced? See here.

OngoingStubbing object used to stub fluently.
Do not create a reference to this returned object.

verify

public static <T> T verify(T mock)

Verifies certain behavior happened once.

Alias to verify(mock, times(1)) E.g:

verify(mock).someMethod("some arg");

Above is equivalent to:

verify(mock, times(1)).someMethod("some arg");

Arguments passed are compared using equals() method.
Read about ArgumentCaptor or ArgumentMatcher to find out other ways of matching / asserting arguments passed.

Although it is possible to verify a stubbed invocation, usually it's just redundant.
Let's say you've stubbed foo.bar().
If your code cares what foo.bar() returns then something else breaks(often before even verify() gets executed).
If your code doesn't care what get(0) returns then it should not be stubbed.
Not convinced? See here.

verify

Verifies certain behavior happened at least once / exact number of times / never. E.g:

verify(mock, times(5)).someMethod("was called five times");
verify(mock, atLeast(2)).someMethod("was called at least two times");
//you can use flexible argument matchers, e.g:
verify(mock, atLeastOnce()).someMethod(anyString());

times(1) is the default and can be omitted

Arguments passed are compared using equals() method.
Read about ArgumentCaptor or ArgumentMatcher to find out other ways of matching / asserting arguments passed.

Parameters:

mock - to be verified

mode - times(x), atLeastOnce() or never()

Returns:

mock object itself

reset

public static <T> void reset(T... mocks)

Smart Mockito users hardly use this feature because they know it could be a sign of poor tests.
Normally, you don't need to reset your mocks, just create new mocks for each test method.

Instead of #reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests.
First potential code smell is reset() in the middle of the test method. This probably means you're testing too much.
Follow the whisper of your test methods: "Please keep us small & focused on single behavior".
There are several threads about it on mockito mailing list.

The only reason we added reset() method is to
make it possible to work with container-injected mocks.
See issue 55 (here)
or FAQ (here).

Don't harm yourself.reset() in the middle of the test method is a code smell (you're probably testing too much).

verifyNoMoreInteractions

You can use this method after you verified your mocks - to make sure that nothing
else was invoked on your mocks.

See also never() - it is more explicit and communicates the intent well.

Stubbed invocations (if called) are also treated as interactions.

A word of warning:
Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method.
verifyNoMoreInteractions() is not recommended to use in every test method.
verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant.
Abusing it leads to overspecified, less maintainable tests. You can find further reading
here.

This method will also detect unverified invocations that occurred before the test method,
for example: in setUp(), @Before method or in constructor.
Consider writing nice code that makes interactions only in test methods.

verifyZeroInteractions

public static void verifyZeroInteractions(java.lang.Object... mocks)

Verifies that no interactions happened on given mocks.

verifyZeroInteractions(mockOne, mockTwo);

This method will also detect invocations
that occurred before the test method, for example: in setUp(), @Before method or in constructor.
Consider writing nice code that makes interactions only in test methods.

See also never() - it is more explicit and communicates the intent well.

doCallRealMethod

Use doCallRealMethod() when you want to call the real implementation of a method.

As usual you are going to read the partial mock warning:
Object oriented programming is more less tackling complexity by dividing the complexity into separate, specific, SRPy objects.
How does partial mock fit into this paradigm? Well, it just doesn't...
Partial mock usually means that the complexity has been moved to a different method on the same object.
In most cases, this is not the way you want to design your application.

However, there are rare cases when partial mocks come handy:
dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
However, I wouldn't use partial mocks for new, test-driven & well-designed code.

See also javadoc spy(Object) to find out more about partial mocks.
Mockito.spy() is a recommended way of creating partial mocks.
The reason is it guarantees real methods are called against correctly constructed object because you're responsible for constructing the object passed to spy() method.

doReturn

Use doReturn() in those rare occasions when you cannot use when(Object).

Beware that when(Object) is always recommended for stubbing because it is argument type-safe
and more readable (especially when stubbing consecutive calls).

Here are those rare occasions when doReturn() comes handy:

When spying real objects and calling real methods on a spy brings side effects

List list = new LinkedList();
List spy = spy(list);
//Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");
//You have to use doReturn() for stubbing:
doReturn("foo").when(spy).get(0);

Overriding a previous exception-stubbing:

when(mock.foo()).thenThrow(new RuntimeException());
//Impossible: the exception-stubbed foo() method is called so RuntimeException is thrown.
when(mock.foo()).thenReturn("bar");
//You have to use doReturn() for stubbing:
doReturn("bar").when(mock).foo();

Above scenarios shows a tradeoff of Mockito's elegant syntax. Note that the scenarios are very rare, though.
Spying should be sporadic and overriding exception-stubbing is very rare. Not to mention that in general
overridding stubbing is a potential code smell that points out too much stubbing.

ignoreStubs

Ignores stubbed methods of given mocks for the sake of verification.
Sometimes useful when coupled with verifyNoMoreInteractions() or verification inOrder().
Helps avoiding redundant verification of stubbed calls - typically we're not interested in verifying stubs.

Warning, ignoreStubs() might lead to overuse of verifyNoMoreInteractions(ignoreStubs(...));
Bear in mind that Mockito does not recommend bombarding every test with verifyNoMoreInteractions()
for the reasons outlined in javadoc for verifyNoMoreInteractions(Object...)
Other words: all *stubbed* methods of given mocks are marked *verified* so that they don't get in a way during verifyNoMoreInteractions().

This method changes the input mocks! This method returns input mocks just for convenience.

timeout

Allows verifying with timeout. It causes a verify to wait for a specified period of time for a desired
interaction rather than fails immediately if had not already happened. May be useful for testing in concurrent
conditions.

It feels this feature should be used rarely - figure out a better way of testing your multi-threaded system

Not yet implemented to work with InOrder verification.

//passes when someMethod() is called within given time span
verify(mock, timeout(100)).someMethod();
//above is an alias to:
verify(mock, timeout(100).times(1)).someMethod();
//passes when someMethod() is called *exactly* 2 times within given time span
verify(mock, timeout(100).times(2)).someMethod();
//passes when someMethod() is called *at least* 2 times within given time span
verify(mock, timeout(100).atLeast(2)).someMethod();
//verifies someMethod() within given time span using given verification mode
//useful only if you have your own custom verification modes.
verify(mock, new Timeout(100, yourOwnVerificationMode)).someMethod();

validateMockitoUsage()explicitly validates the framework state to detect invalid use of Mockito.
However, this feature is optional because Mockito validates the usage all the time... but there is a gotcha so read on.

Examples of incorrect use:

//Oups, someone forgot thenReturn() part:
when(mock.get());
//Oups, someone put the verified method call inside verify() where it should be outside:
verify(mock.execute());
//Oups, someone has used EasyMock for too long and forgot to specify the method to verify:
verify(mock);

Mockito throws exceptions if you misuse it so that you know if your tests are written correctly.
The gotcha is that Mockito does the validation next time you use the framework (e.g. next time you verify, stub, call mock etc.).
But even though the exception might be thrown in the next test,
the exception message contains a navigable stack trace element with location of the defect.
Hence you can click and find the place where Mockito was misused.

Sometimes though, you might want to validate the framework usage explicitly.
For example, one of the users wanted to put validateMockitoUsage() in his @After method
so that he knows immediately when he misused Mockito.
Without it, he would have known about it not sooner than next time he used the framework.
One more benefit of having validateMockitoUsage() in @After is that jUnit runner will always fail in the test method with defect
whereas ordinary 'next-time' validation might fail the next test method.
But even though JUnit might report next test as red, don't worry about it
and just click at navigable stack trace element in the exception message to instantly locate the place where you misused mockito.

Bear in mind that usually you don't have to validateMockitoUsage()
and framework validation triggered on next-time basis should be just enough,
mainly because of enhanced exception message with clickable location of defect.
However, I would recommend validateMockitoUsage() if you already have sufficient test infrastructure
(like your own runner or base class for all tests) because adding a special action to @After has zero cost.

MockSettings has been introduced for two reasons.
Firstly, to make it easy to add another mock settings when the demand comes.
Secondly, to enable combining different mock settings without introducing zillions of overloaded mock() methods.