How to use overrideDefaultAnswer method of org.mockito.configuration.MockitoConfiguration class

For the mocks initialization, using the runner or the MockitoAnnotations.initMocks are strictly equivalent solutions. From the javadoc of the MockitoJUnitRunner :

JUnit 4.5 runner initializes mocks annotated with Mock, so that explicit usage of MockitoAnnotations.initMocks(Object) is not necessary. Mocks are initialized before each test method.

The first solution (with the MockitoAnnotations.initMocks) could be used when you have already configured a specific runner (SpringJUnit4ClassRunner for example) on your test case.

The second solution (with the MockitoJUnitRunner) is the more classic and my favorite. The code is simpler. Using a runner provides the great advantage of automatic validation of framework usage (described by @David Wallace in this answer).

Both solutions allows to share the mocks (and spies) between the test methods. Coupled with the @InjectMocks, they allow to write unit tests very quickly. The boilerplate mocking code is reduced, the tests are easier to read. For example:

@RunWith(MockitoJUnitRunner.class)
public class ArticleManagerTest {

    @Mock private ArticleCalculator calculator;
    @Mock(name = "database") private ArticleDatabase dbMock;
    @Spy private UserProvider userProvider = new ConsumerUserProvider();

    @InjectMocks private ArticleManager manager;

    @Test public void shouldDoSomething() {
        manager.initiateArticle();
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        manager.finishArticle();
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Pros: The code is minimal

Cons: Black magic. IMO it is mainly due to the @InjectMocks annotation. With this annotation "you loose the pain of code" (see the great comments of @Brice)

The third solution is to create your mock on each test method. It allow as explained by @mlk in its answer to have "self contained test".

public class ArticleManagerTest {

    @Test public void shouldDoSomething() {
        // given
        ArticleCalculator calculator = mock(ArticleCalculator.class);
        ArticleDatabase database = mock(ArticleDatabase.class);
        UserProvider userProvider = spy(new ConsumerUserProvider());
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.initiateArticle();

        // then 
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        // given
        ArticleCalculator calculator = mock(ArticleCalculator.class);
        ArticleDatabase database = mock(ArticleDatabase.class);
        UserProvider userProvider = spy(new ConsumerUserProvider());
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.finishArticle();

        // then
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Pros: You clearly demonstrate how your api works (BDD...)

Cons: there is more boilerplate code. (The mocks creation)

My recommandation is a compromise. Use the @Mock annotation with the @RunWith(MockitoJUnitRunner.class), but do not use the @InjectMocks :

@RunWith(MockitoJUnitRunner.class)
public class ArticleManagerTest {

    @Mock private ArticleCalculator calculator;
    @Mock private ArticleDatabase database;
    @Spy private UserProvider userProvider = new ConsumerUserProvider();

    @Test public void shouldDoSomething() {
        // given
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.initiateArticle();

        // then 
        verify(database).addListener(any(ArticleListener.class));
    }

    @Test public void shouldDoSomethingElse() {
        // given
        ArticleManager manager = new ArticleManager(calculator, 
                                                    userProvider, 
                                                    database);

        // when 
        manager.finishArticle();

        // then 
        verify(database).removeListener(any(ArticleListener.class));
    }
}

Pros: You clearly demonstrate how your api works (How my ArticleManager is instantiated). No boilerplate code.

Cons: The test is not self contained, less pain of code

The following code sample from this Mockito documentation illustrates how to mock a void method:

doThrow(new RuntimeException()).when(mockedList).clear();

// following throws RuntimeException:
mockedList.clear();

The following, running under Mockito 1.9.0 and JUnit 4.8.2, does not print anything to my console:

import static org.mockito.Mockito.*;

import org.junit.Test;

public class TestNonCall {
  public class TestClass {
    public String test() {
      System.out.println("test called!");
      return "test";
    }
  }

  @Test
  public void doTest() {
    final TestClass mock = mock(TestClass.class);

    when(mock.test()).thenReturn("mock!");
  }
}

Further, if I put a breakpoint in the test() method it is never hit.

Perhaps post more code? It looks like your example is not complex enough to demonstrate the behaviour you're having problems with.

Also: are you using the latest version of Mockito?

Edit: New Thought: Are You Mocking a Final Method?

If you add a final modifier to the method you are mocking, you get the behaviour you reported.

This is because Mockito does not mock final and static methods. Instead, it delegates the calls to the real implementation.

Might your actual code be attempting to mock a final method?

If so, you can use PowerMock, which is an extension to Mockito that allows mocking final methods.

You would need to add the following annotations to your test case class:

@RunWith(PowerMockRunner.class)
@PrepareForTest(TestClass.class)
public class TestNonCall {
  // ...
}

and mock the class using the PowerMock method in your test method:

final TestClass mock = PowerMockito.mock(TestClass.class);

then proceed as usual.

Why it doesn't work

Well your problem here is that TransactionTemplate in your test is a mock. As such it has the same interface as TransactionTemplate but it does not know how to behave. You are in charge of its implementation - that's the whole point of mocks. You are explicitly calling template.execute() in your code and that is why your first verify passes. But that execute() isn't the one from Spring (or more precisely template in your test isn't an instance of Spring's TransactionTemplate, it's only a mock of it) - it's, well lets say it's "empty" as it is invoked on a mock and you did not tell the mock how invoking execute() on it should behave.

How I would fix it

In cases like this I would really discourage you from such unit tests because you are testing implementation here. What you should test, at least according to me, is the functionality meaning given certain conditions, when something happens then some result should occur. This would require changing this to an integration test (using lets say DBUnit or anything else) and asserting if you actually deleted what you were supposed to delete. I mean what do you really care about - knowing that some methods got invoked or that something you hoped for actually happened?

How you can, but IMHO shouldn't, fix it.

But if you really want to test that anonymous piece of code then I would simply extract it (the whole anonymous class) to a separate class and write a unit test just for that new class and more precisely for it's doInTransaction() method. In that case you would create it using new, setting a mock DataWarehouseMessageDao in it and simply do your verify().

A better way to accomplish that would probably be:

when(someService.someMethod(id)).thenThrow(new AccountNotFoundException());

then the compiler should infer the type correctly.

If someService.someMethod(id) has return type void you can do:

doThrow(new AccountNotFoundException()).when(someService).someMethod(id);

Please refer to the official Mockito documentation for examples like this using thenThrow. The documentation is very clear on this point.

You can also check the following StackOverflow question which is very similar (if not an exact duplicate):

How to mock and assert a thrown exception

To answer your second question first. If you're using JUnit 4, you can annotate your test with

@Test(expected=MyException.class)

to assert that an exception has occured. And to "mock" an exception with mockito, use

when(myMock.doSomething()).thenThrow(new MyException());

Just to complete the picture:

The latest version of Mockito 2 very well supports mocking of final classes. But you have to explicitly enable this new experimental feature first!

( see here on how to do that - it boils down to add a file mockito-extensions/org.mockito.plugins.MockMaker to your classpath, containing the value mock-maker-inline )

But of course: you only mock something if you have to. Your desire to mock Enum instances is most likely driven by either not understanding that - or because you created hard to test code here. In that sense the real answer would be to look into ways that avoid this kind of mocking in the first place.

You can use a Mockito Spy for this. If you setup anotherObj as a spy you can verify method calls on that object. In your example you need to make sure that the call to foo uses the spy instead of an ordinary implementation of anotherObj. The spy is setup something like this:

AnotherClass anotherObjSpy = Mockito.spy(new AnotherClass());
// do stuff -- e.g. anotherObjSpy.foo(...);
verify(anotherObjSpy).codePath1(...);

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