If you want the mocked method to call a method on (or otherwise alter) a parameter, you'll need to write an Answer as in this question ("How to mock a void return method affecting an object").

From Kevin Welker's answer there:

doAnswer(new Answer() {
    Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        ((MyClass)args[0]).myClassSetMyField(NEW_VALUE);
        return null; // void method, so return null
    }
}).when(mock).someMethod();

Note that newer best-practices would have a type parameter for Answer, as in Answer<Void>, and that Java 8's lambdas can compress the syntax further. For example:

doAnswer(invocation -> {
  Object[] args = invocation.getArguments();
  ((MyClass)args[0]).myClassSetMyField(NEW_VALUE);
  return null; // void method in a block-style lambda, so return null
}).when(mock).someMethod();

org.mockito.runners.MockitoJUnitRunner is now indeed deprecated, you are supposed to use org.mockito.junit.MockitoJUnitRunner instead. As you can see only the package name has changed, the simple name of the class is still MockitoJUnitRunner.

Excerpt from the javadoc of org.mockito.runners.MockitoJUnitRunner:

Moved to MockitoJUnitRunner, this class will be removed with Mockito 3

The article isn't very clear as it misses out the setup steps. By visiting the GitHub project linked in the article, you can see the full source code which explains those missing steps:

1) The code samples are extracted from a test class testing a specific activity. As part of the setup (i.e. in @Before), it replaces the Activity's reference to a GitHub API implementation with a mock one. It then calls the Activity's onCreate().

2) During onCreate(), the activity makes a call to the now-replaced GitHub API, passing in its Callback object.

Those first two steps explain why the Mockito.verify(mockApi).repositories(Mockito.anyString(), cb.capture()); step at the beginning of each test works. As the test is run after @Before, the mockApi has indeed had a call on its repositories() method.

The rest of the code is easier to understand once that's in place. As he's only created a mockApi, but not changed the actual Callback being used, the activity's content is changed. The rest of the code then verifies that those changes have taken place, either by checking a ListView or the Toasts.

So to answer your question, you need to:

1) At the start of your test method, replace the AuthAPI's loginService object with your mockApi object, then call AuthAPI.Login().

2) Use verify() as you already are to check that the function has been called.

3) Create a sample AuthObject and pass it to the cb.getValue().success() function.

4) Obtain the AuthObject from your Bus and assert that it is the same one you sent to the callback.success() function.

This tests that your AuthAPI.Login() correctly sends to your Bus the AuthObject that it would retrieve from Retrofit.

(I realise the SO question was written some time ago, but as I came across the same article and had the same confusion very recently, I thought this answer could be useful for others.)

I was intrigued by this post and the comments left by @David so I decided to code a working example for those who follow like me

/*
 * class to test
 */
public class A {

    public void methodA(String str) {
        this.methodB(str);
    }

    protected void methodB(String str) {
        // some implementation
    }
}

We want to assert that the value being passed into methodB() is what we expect. Reading up on the ArgumentCaptor led me to discover the equivalent Captor Annotation

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.verify;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MultipleMethodCallTest {

    @Spy
    A a = new A();

    @Captor ArgumentCaptor<String> captor;

    @Test
    public void captureSecondMethodCallArgument() throws Exception {

        // EXPECTED

        String greeting = "hello world";

        // PERFORM TEST

        a.methodA(greeting);

        // ASSERT

        verify(a).methodB(captor.capture());

        assertEquals(greeting, captor.getValue());
    }
}

This example was tested with

• mockito-all-1.8.5.jar
• junit-4.8.2.jar

It depends if you are using (declaring) the runner or not.

If you use the runner, you don't need to call MockitoAnnotations.initMocks() yourself - the runner calls it for you.

Usually we go for the runner. When you want to use other runners, though (like Spring's), you can call .initMocks() yourself.

Just to be clear, the MockitoAnnotations.initMocks(this) will:

• Instantiate the field annotated with @InjectMocks
• Create a mock version of every field annotated with @Mock
• Inject the @Mocks in the @InjectMocks variable's fields (or call its constructors or use its setters - it depends on what kind of Dependency Injection you use)

Mockito runner, initMocks and rule code samples

The three code samples below should be equivalent.

With runner:

This first snippet uses the runner, making the call to initMocks() unnecessary.

@RunWith(MockitoJUnitRunner.class)
public class MyClassTest {

    @Mock private MyDependency myDependency;
    @InjectMocks private MyClass myClass;

    @Test
    public void myClass_should_get_stuff_from_dependency() {
        when(myDependency.getStuff()).thenReturn("stuff!");

        assertThat(myClass.getDependencyStuff(), is("stuff!"));
    }
}

Without runner + with manual call to .initMocks():

This other does not use the runner, thus the need for the setUp() method calling our initMocks() friend.

// notice there is no runner
public class MyClassTest {

    @Mock private MyDependency myDependency;
    @InjectMocks private MyClass myClass;

    // but now you have to call initMocks() yourself
    @Before
    public void setUp() throws Exception {
          MockitoAnnotations.initMocks(this);
    }

    @Test
    public void myClass_should_get_stuff_from_dependency() {
        when(myDependency.getStuff()).thenReturn("stuff!");

        assertThat(myClass.getDependencyStuff(), is("stuff!"));
    }
}

Without runner or manual call, using @Rule:

Finally, as pointed out in the comments (thanks @StefanBirkner), since version 1.10.17, there is also the possibility of using a JUnit @Rule called MockitoRule:

public class MyClassTest {

    @Rule
    public MockitoRule rule = MockitoJUnit.rule();

    @Mock private MyDependency myDependency;
    @InjectMocks private MyClass myClass;

    @Test
    public void myClass_should_get_stuff_from_dependency() {
        when(myDependency.getStuff()).thenReturn("stuff!");

        assertThat(myClass.getDependencyStuff(), is("stuff!"));
    }
}

You should also mock the next() method to have it return true the first time it's called, as mockito will return false by default.

Mockito.when(resultSetMock.next()).thenReturn(true).thenReturn(false);

You either have to specify no matchers, or all the arguments need matches. So this:

when(userSubModuleDao.findById((any(UserSubModuleId.class)),false))

should be:

when(userSubModuleDao.findById(any(UserSubModuleId.class), eq(false)))

(I've removed the redundant brackets from around the any call.)

From the Matchers documentation:

Warning:

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

Although not a direct answer to your question, however I suggest that you move away from field injection and use constructor injection instead (makes code more readable and testable).

Your code would look like:

class Patient {

  private final Syringe syringe;

  @Inject
  public Patient(Syringe syringe) {
    System.out.println("That hurt like crazy!");
  }

}

Then your test would simply be:

@RunWith(MockitoJUnitRunner.class)
class TestCase {

  @Mock
  Syringe siringeMock;

  Patient patient;

  @Before
  public void setup() {
     patient = new Patient(siringeMock);
  }

}

Update

As suggested by Erik-Karl in the comments, you could use @InjectMocks to get rid of the setup method. The solution works because Mockito will use the appropriate constructor injection (as described here). The code would then look like:

@RunWith(MockitoJUnitRunner.class)
class TestCase {

  @Mock
  Syringe siringeMock;

  @InjectMocks
  Patient patient;

}

Definitely! Mockito is awesome. You can use an ArgumentCaptor to capture the Employee parameter and then do some assertions.

(example taken from the previous link)

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

Or the new funky way using the @Captor annotation

@Captor ArgumentCaptor<AsyncCallback<Foo>> captor;

@Before
public void init(){
   MockitoAnnotations.initMocks(this);
}

@Test public void shouldDoSomethingUseful() {
   //...
   verify(mock).doStuff(captor.capture());
   assertEquals("foo", captor.getValue());
}