You do not need mockito to test this method, only a java.io.StringWriter.

Here is how you can write the test for a nominal use:

@Test
void status_written_in_csv_format() {
    // Setup
    WriteCsvToResponse objectUnderTest = new WriteCsvToResponse ();
    StringWriter stringWriter = new StringWriter();
    PrintWriter printWriter = new PrintWriter(stringWriter);

    // Given
    Status status = ...

    // When
    objectUnderTest.writeStatus(printWriter, status);

    // Then
    String actualCsv = stringWriter.toString();
    assertThat(actualCsv.split("\n"))
       .as("Produced CSV")
       .containsExactly(
         "id,storeId,status",
         "42,142,OK");
}

This example assume some things about your Status object, but you have the general idea. For assertions, I use AssertJ, but you can do the same with JUnit5 built-in assertions.

Hope this helps !

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!"));
    }
}

Mockito has an isNull matcher, where you can pass in the name of the class. So if you need to use it with other matchers, the correct thing to do is

verify(client).method(eq("String"),isNull(Class<?>.class));

This is now deprecated, see the answer below for the new method - https://stackoverflow.com/a/41250852/1348

This question is ancient, but Mockito v2.1.0+ now has a built-in feature for this.

verify(mock, description("This will print on failure")).someMethod("some arg");

More examples included from @Lambart's comment below:

verify(mock, times(10).description("This will print if the method isn't called 10 times")).someMethod("some arg");
verify(mock, never().description("This will print if someMethod is ever called")).someMethod("some arg");
verify(mock, atLeastOnce().description("This will print if someMethod is never called with any argument")).someMethod(anyString());

I changed TestCompile to androidTestCompile and it's worked without problems.

testCompile 'junit:junit:4.12'

to

androidTestCompile 'junit:junit:4.12'

Mockito can stub consecutive behavior with the same parameters—forever repeating the final instruction—but they all have to be part of the same "chain". Otherwise Mockito effectively thinks you've changed your mind and overwrites your previously-mocked behavior, which isn't a bad feature if you've established good defaults in a setUp or @Before method and want to override them in a specific test case.

The general rules for "which Mockito action will happen next": The most-recently-defined chain that matches all arguments will be selected. Within the chain, each action will happen once (counting multiple thenReturn values if given like thenReturn(1, 2, 3)), and then the last action will be repeated forever.

// doVerb syntax, for void methods and some spies
Mockito.doThrow(new IOException())
    .doNothing()
    .when(mapper).writeValue(
        (OutputStream) Matchers.anyObject(), Matchers.anyObject());

This is the equivalent of chained thenVerb statements in the more-common when syntax, which you correctly avoided here for your void method:

// when/thenVerb syntax, to mock methods with return values
when(mapper.writeValue(
        (OutputStream) Matchers.anyObject(), Matchers.anyObject())
    .thenThrow(new IOException())
    .thenReturn(someValue);

Note that you can use static imports for Mockito.doThrow and Matchers.*, and switch to any(OutputStream.class) instead of (OutputStream) anyObject(), and wind up with this:

// doVerb syntax with static imports
doThrow(new IOException())
    .doNothing()
    .when(mapper).writeValue(any(OutputStream.class), anyObject());

See Mockito's documentation for Stubber for a full list of commands you can chain.

Alright, once I realised that the class was being proxied due to the @Transactional annotation, the solution to the problem became clearer. What I needed to do was unwrap the proxy, and set the mocked object directly on that:

So in my AbstractIntegrationTest:

/**
 * Checks if the given object is a proxy, and unwraps it if it is.
 *
 * @param bean The object to check
 * @return The unwrapped object that was proxied, else the object
 * @throws Exception
 */
public final Object unwrapProxy(Object bean) throws Exception {
    if (AopUtils.isAopProxy(bean) && bean instanceof Advised) {
        Advised advised = (Advised) bean;
        bean = advised.getTargetSource().getTarget();
    }
    return bean;
}

Then in my @Before:

@Mock
private ProcessHelper processHelper;

@Before
public void setUp() throws Exception {
    MockitoAnnotations.initMocks(this);

    IXMLBatchProcessor iXMLBatchProcessor = (IXMLBatchProcessor) unwrapProxy(xmlProcessor);
    ReflectionTestUtils.setField(iXMLBatchProcessor , "processHelper", processHelper);
}

This left all the @Autowired classes intact, while injecting the correct mocked object.

You should avoid creating business objects with new in a Spring application. You should always get them from the application context - it will ease mocking them in your test.

In your use case, you should simply create your validator as a bean (say defaultTerminationValidator) and inject it in your controller :

public class TerminationController extends AbstractController {

    private TerminationValidator terminationValidator;

    @Autowired
    public setDefaultTerminationValidator(TerminationValidator validator) {
        this.terminationValidator = validator;
    }

    @InitBinder("termination")
    public void initBinder(WebDataBinder binder, HttpServletRequest request) {
        binder.setValidator(terminationValidator);
        binder.setAllowedFields(new String[] { "termId[**]", "terminationDate",
                "accountSelection", "iban", "bic" });
    }

    [...]
}

That way, you will be able to simply inject a mock in your test.

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