How to use testStaticMockWithVerification method of org.mockitoinline.StaticMockRuleTest class

Mockito 1.9.0 introduced listeners and now bundles a verbose logger:

So basically if you want simple and stupid logs, just do the following:

List mockWithLogger = mock(List.class, withSettings().verboseLogging());

See #verboseLogging() for more information

Cheers,

You may have some trouble with any or argThat for primitive-type arguments to when and verify. Those Object-centric methods do their work with side-effects correctly, but they tend to return null for a dummy return value, which doesn't work for Java unwrapping primitives via auto-boxing.

Luckily, the org.mockito.ArgumentMatchers class has a full complement of primitive-centric methods (of which I've listed the int methods here):

static int anyInt()
static int eq(int value)
static int intThat(org.hamcrest.ArgumentMatcher<java.lang.Integer> matcher)

See all of them at the documentation for the ArgumentMatchers class.

This occurs because you are using any() along with a real parameter VehicleCollection.class of type Class<VehicleCollection>.

Change it just like below, and you should be fine:

 when(queryBus.handle(any(VehicleCollection.class), any(GetVehicle.class))).thenAnswer(null);

Mockito explains why:

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):

    // Correct - eq() is also an argument matcher
    verify(mock).someMethod(anyInt(), anyString(), eq("third argument"));


    // Incorrect - exception will be thrown because third argument is given without argument matcher.
    verify(mock).someMethod(anyInt(), anyString(), "third argument");    

In the end, this is all about wording.

When you think of "correct" in its very fundamental sense, as in correctness, then the answer is simply: no.

You see, the goal of an integration test is to ensure that your integrated system (consisting of multiple, different components) functions as expected. The purpose of an integration test is to verify that your "plumbing" of components works as expected. Therefore: you can't verify that your system works when parts of that system are mocked out.

But then, you can think "correctness" less strictly.

Example: companies selling cars have to test ECUs. Basically a piece of hardware, running a potentially huge software stack. These ECUs normally operate within cars. So when you want to integration test an ECU, you would have to put the ECU into a car for testing, right? A car that probably doesn't exist yet. The solution here: there are hardware emulators. You plug the ECU into that emulator, and the ECU "thinks" that sits inside a real car.

So: there are good arguments to claim "a true integration test can't use mocking", but at the same time, in the real world, such "mocking" happens all the time.

The real answer is therefore: it depends on context. Therefore there isn't a universal answer. Instead, this is about communication. You "simply" have to ensure that all people in your group/org have the same understanding of such terms.

The term itself can be interpreted in different ways. You (jointly!) pick that definition that best fits your needs, to then make sure all people contributing to your project share that view (or at least know about it).

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

Since Mockito 2.x this has been replaced by implementations of org.mockito.listeners.MockitoListener which you engage like so:

Mockito.framework().addListener()

For example:

@Test
public void listAllMocks() {
    List<Object> mocks = new ArrayList<>();

    // can be replaced by a lambda if using java 8+
    Mockito.framework().addListener(new MockCreationListener() {
        @Override
        public void onMockCreated(Object mock, MockCreationSettings settings) {
            mocks.add(mock);
        }
    });

    A a = Mockito.mock(A.class);
    B b = Mockito.mock(B.class);

    // ... do something with a, b

    // verify
    assertThat(mocks.size(), is(2));
    assertThat(mocks, hasItem(a));
    assertThat(mocks, hasItem(b));
}

There's no way to use anyMapOf to do this. It's designed to help with the simple case of mapping simple classes to simple classes in Java 7, and yours is more complex than that.

Java 8 parameter inference improved, so in Java 8, you can just use any().

verify(dataProcessor).process(Matchers.any());

Barring that, the best way to make this look is either like you wrote above:

verify(dataProcessor).process(Matchers.<Map<String, Set<String>>>any());

Or by extracting the matcher to a static function, which gives Java just enough information it needs to infer the type on its own:

@Test public void yourTest() {
  // ...
  verify(dataProcessor).process(anyStringSetMap());
}

private static Map<String, Set<String>> anyStringSetMap() {
  return any();
}

(Caveat: Note that the return value of anyStringSetMap() is null; it's the side-effect of calling any that you're looking for. The extracted method is just to inform the Java compiler of the expected return type; beware that doing anything fancier will probably break in really-quite-interesting ways.)

Using @TestConfiguration rather than using the @MockBean might help to solve this problem.

@TestConfiguration
    static class Configuration {
        @Bean
        public BeanToMock name() {
            // return mock object           
        }
    }

And annotating the test class with @ContextConfiguration:

@ContextConfiguration(classes = TestClassName.Configuration.class)

It is quite easy with Mockito:

@RunWith(MockitoJUnitRunner.class)
public class RuleIdValidatorTest {
    @Mock
    private RuleStore ruleStoreMock;

    @InjectMocks
    private RuleIdValidator ruleIdValidator;

    @Test
    public void someTest() {
        when(ruleStoreMock.doSomething("arg")).thenReturn("result");

        String actual = ruleIdValidator.doSomeThatDelegatesToRuleStore();

        assertEquals("result", actual);
    }
}

Read more about @InjectMocks in the Mockito javadoc or in a blog post that I wrote about the topic some time ago.

Available as of Mockito 1.8.3, enhanced in 1.9.0.