mockStatic

Creates class 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.

mockStatic

The number of configuration points for a mock grows so we need a fluent
way to introduce new configuration without adding more and more
overloaded PowerMockito.mockStatic() methods. Hence MockSettings.

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?

See also Mockito.withSettings()

Parameters:

classToMock - class to mock

mockSettings - additional mock settings

mock

public static <T> T mock(java.lang.Class<T> type)

Creates a mock object that supports mocking of final and native methods.

Type Parameters:

T - the type of the mock object

Parameters:

type - the type of the mock object

Returns:

the mock object.

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?

See also Mockito.withSettings()

See examples in javadoc for Mockito class

Parameters:

classToMock - class or interface to mock

mockSettings - additional mock settings

Returns:

mock object

spy

public static <T> T spy(T object)

Spy on objects that are final or otherwise not "spyable" from
normal Mockito.

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.

verifyStatic

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

verifyStatic(times(5));
ClassWithStaticMethod.someStaticMethod("was called five times");
verifyStatic(atLeast(2));
ClassWithStaticMethod.someStaticMethod("was called at least two times");
//you can use flexible argument matchers, e.g:
verifyStatic(atLeastOnce());
ClassWithStaticMethod.someMethod(<b>anyString()</b>);

verifyNoMoreInteractions

Checks if any of given mocks (can be both instance and class mocks) has
any unverified interaction. Delegates to the orignal
Mockito.verifyNoMoreInteractions(Object...) if the mock is not a
PowerMockito mock.

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

See also Mockito.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 (can be both
instance and class mocks). Delegates to the orignal
Mockito.verifyNoMoreInteractions(Object...) if the mock is not a
PowerMockito mock.

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 Mockito.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 Mockito.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
Mockito.when(Object).

Beware that Mockito.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:

1. 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);

2. 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 ellegant syntax. Note that
the scenarios are very rare, though. Spying should be sporadic and
overriding exception-stubbing is very rare.