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 argument matcher.

5. Stubbing void methods with exceptions

6. Verification in 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");

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.

7. Making sure interaction(s) never happened on mock

//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);

Instead of verifyZeroInteractions() you can call verifyNoMoreInteractions()
but the first one is more explicit and can read better.

8. Finding redundant invocations

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 an intent well.

9. Shorthand for mocks creation - @Mock annotation

Minimizes repetitive mock creation code.

Makes the test class more readable.

Makes the verification error easier to read because field name
is used to identify the mock.

10. (**New**) Stubbing consecutive calls (iterator-style stubbing)

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:

11. (**Totally New**) Stubbing with callbacks

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

Stubbing can be overridden: for example common stubbing can go to fixture
setup but test methods can override it.

Once stubbed, mocked 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.

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.

verifyNoMoreInteractions

Throws an AssertionError if any of given mocks has any unverified
interaction.

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 an intent well.

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

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.

doReturn

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

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

However, there are 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)
stub(spy.get(0)).toReturn("foo");
//You have to use doReturn() for stubbing:
doReturn("foo").when(spy).get(0);

2. Overriding a previous exception-stubbing:

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

Above scenario shows a tradeoff of Mockito's ellegant syntax. The scenario is very rare, though.