This is the old way to squirrel-cage create() in Mockito, pre 1.9.5.rc1.

import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;
import static org.junit.Assert.fail;
import static org.mockito.Matchers.any;
import static org.mockito.Matchers.anyObject;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;
import static org.mockito.AdditionalAnswers.returnsFirstArg;
import static org.mockito.BDDMockito.given;

import org.junit.Before;
import org.junit.Test;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.MockitoAnnotations;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
import org.bson.types.ObjectId;

...

@Test
public void testCreate_oldway()
{
    Answer< Account > answer = new Answer< Account >()
    {
        public Account answer( InvocationOnMock invocation ) throws Throwable
        {
            Object[] args = invocation.getArguments();
            Account account = ( Account ) args[ 0 ];
            account.setOid( JACK_OID );
            account.setIdentityoid( JACK_ID_OID );
            account.setPassword( JACK_PASS );
            account.setPartneroid( ACME_OID );
            return account;
        }
    };
    when( dao.create( any( Account.class ) ) ).thenAnswer( answer );

    when( partnerDao.readByOid( ACME_OID ) ).thenReturn( ACME );
    when( identityDao.readByOid( JACK_ID_OID ) ).thenReturn( JACK_ID );
    when( dao.readByIdentityAndPartneroids( any( ObjectId.class ), any( ObjectId.class ) ) ).thenReturn( JACK );

    AccountDto JACK_DTO = JACK.dto();
    JACK_DTO.setOid( JACK_OID );
    JACK_DTO.setPassword( JACK_PASS );      // (have to inject this artificially)

    try
    {
        manager.create( null, JACK_ID_OID, JACK_DTO );
        fail( "Shouldn't get here because account already exists!" );
    }
    catch( AppException e )
    {
        log.info( "Test is successful if you get here." );
        assertTrue( e.getHttpStatus() == Status.CONFLICT );
    }
}

The new way began in Mockito, 1.9.5.rc1.

@Test
public void testCreate_newway() throws AppException
{
    given( dao.create( ( Account ) anyObject() ) ).will( returnsFirstArg() );
    when( partnerDao.readByOid( ACME_OID ) ).thenReturn( ACME );
    when( identityDao.readByOid( JACK_ID_OID ) ).thenReturn( JACK_ID );
    when( dao.readByIdentityAndPartneroids( any( ObjectId.class ), any( ObjectId.class ) ) ).thenReturn( null );

    AccountDto JACK_DTO = JACK.dto();
    JACK_DTO.setPartneroid( ACME_OID );
    JACK_DTO.setPassword( JACK_PASS );      // (have to inject this artificially)

    Account result = manager.create( null, JACK_ID_OID, JACK_DTO );

    verify( dao ).create( result );
    assertNotNull( result );
    assertTrue( EntityTestSupport.verifyPasswordHandled( result, JACK_PASS ) );
    assertTrue( EntityTestSupport.verifyAccountResult( JACK, result ) );
}

Sometimes Mockito is grumpy when you use anyObject() in an argument list with raw types (string literals and the like—see "eat this" below). The error displayed will tell you, but you need to bracket those with eq():

import static org.mockito.Matchers.anyObject;
...
import static org.mockito.Matchers.eq;
@Test
public void testCreate_newway() throws AppException
{
    ...
    when( mocked.method( eq( "eat this" ), ( SomeClass ) anyObject() ) ).thenReturn( something );
    ...
}

This is a way to instantiate an abstract class that you want to test. After doing this, it's as if SomeClass were not abstract.

    public class SomeClassTest
    {
        private SomeClass real;

        @Before
        public void setUp()
        {
            Mockito.mock( SomeClass.class, Mockito.CALLS_REAL_METHODS );
            real.setX( 9 );
            ...
        }

        @Test
        public void testSetX()
        {
            real.setX( 9 );
            assertEquals( 9, read.getX() );
        }
    }

    public abstract class SomeClass
    {
        private int x;
        ...
        public void setX( int x ) { this.x = x; }
        public int getX() { return this.x; }
        ...
    }

This still picks on me from time to time. I'm debugging through some code expecting not to execute a method call because it's mocked, but it crashes down inside (or does the wrong thing down inside) and I ask myself why Mockito didn't mock the method.

The answer is that Mockito will not mock methods that are static or final. In order to do that, remove final, re-interface above the class or visit PowerMock's functionality.

For this code, ...

    when( mockedObject.stubbedMethod() ).thenReturn( X );

...the compiler give you this error:

    Cannot resolve method 'thenReturn( X )'

This only means that X doesn't match what stubbedMethod() should return.

Concrete example: I have mocked AmazonSqsClient and want to specify how method GetQueueAttributes() should pretend to behave. I get:

Cannot resolve method 'thenReturn(resultMap)'

...in this code:

public class HaveFunWithSqs
{
  private SqsOperations         sqsOperations;
  @Mock private AmazonSqsClient awsClient;

  @BeforeMethod
  public void setup()
  {
    MockitoAnnotations.initMocks( this );
    sqsOperations = new SqsOperations( /* stuff about queue */ );
  }

  @Test
  public void test()
  {
    List< String > attributeNames = new ArrayList<>( 1 );
    attributeNames.add( "ApproximateNumberOfMessages" );
    Map< String, String > resultMap = new HashMap<>( 1 );
    resultMap.put( "ApproximateNumberOfMessages", "27" );

    when( awsClient.getQueueAttributes( attributeNames ) ).thenReturn( resultMap );

    int result = sqsOperations.getMessageCount();

    assertEqual( result, 27 );
  }
}

What I forgot was that AmazonSqsClient.getQueueAttribtes() returns the intermediate object, GetQueueAttributesResult; the resulting map I'm after is inside that:

@Test
public void test()
{
    List< String > attributeNames = new ArrayList<>( 1 );
    attributeNames.add( "ApproximateNumberOfMessages" );
    Map< String, String > resultMap = new HashMap<>( 1 );
    resultMap.put( "ApproximateNumberOfMessages", "27" );
    GetQueueAttributesResult attributesResult = new GetQueueAttributesResult();
    attibutesResult.setAttributes( resultMap );

    when( awsClient.getQueueAttributes( attributeNames ) ).thenReturn( attributesResult );

    int result = sqsOperations.getMessageCount();

    assertEqual( result, 27 );
}

Martin Fowler:

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production.

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

From xunitpattern:

Mock Object: that implements the same interface as an object on which the SUT depends. We can use a Mock Object as an observation point when we need to do Behavior Verification to avoid having an Untested Requirement (see Production Bugs on page X) caused by an inability to observe side-effects of invoking methods on the SUT.

Stub: This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code (see Production Bugs on page X) within the SUT. A key indication for using a Test Stub is having Untested Code caused by the inability to control the indirect inputs of the SUT

Fake: We acquire or build a very lightweight implementation of the same functionality as provided by a component that the SUT depends on and instruct the SUT to use it instead of the real.

Another look...

Fake: a class that implements an interface but contains fixed data and no logic. Simply returns "good" or "bad" data depending on the implementation.

Mock: a class that implements an interface and allows the ability to dynamically set the values to return/exceptions to throw from particular methods and provides the ability to check if particular methods have been called/not called.

Stub: Like a mock class, except that it doesn't provide the ability to verify that methods have been called/not called.

And...

Stub: an object that provides predefined answers to method calls.

Mock: an object on which you set expectations.

Fake: an object with limited capabilities (for the purposes of testing), e.g. a fake web service.

Mocking everything in a test diminishes (radically) the good returns of unit tests. This decreases confidence because mocks are not real. It's crucial that unit tests test something, and that something should be logic—business rules, the outcome of sorting or parsing, etc. If the code, mocked up, is only contributing coordinating logic, that's not adding a log of value. Low-value unit tests are nevertheless code that must be carried around and maintained—at some expense.