Initialising mock objects – MockIto

by

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

More Related Contents:

  1. How to mock a final class with mockito
  2. How to mock private method for testing using PowerMock?
  3. Test class with a new() call in it with Mockito
  4. Difference between @Mock, @MockBean and Mockito.mock()
  5. Testing Private method using mockito
  6. Mock a constructor with parameter
  7. Mockito: Trying to spy on method is calling the original method
  8. Mockito : how to verify method was called on an object created within a method?
  9. How to tell a Mockito mock object to return something different the next time it is called?
  10. Using PowerMockito.whenNew() is not getting mocked and original method is called
  11. How to use ArgumentCaptor for stubbing?
  12. How to mock new Date() in java using Mockito
  13. Mockito How to mock and assert a thrown exception?
  14. Mockito – NullpointerException when stubbing Method
  15. How to verify that a specific method was not called using Mockito?
  16. Mocking Logger and LoggerFactory with PowerMock and Mockito
  17. PowerMock, mock a static method, THEN call real methods on all other statics
  18. junit testing for user input using Scanner
  19. Why is my class not calling my mocked methods in unit test?
  20. How do I mock a REST template exchange?
  21. Why are my mocked methods not calld when executing a unit test?
  22. Forming Mockito “grammars”
  23. JUnit tests for AspectJ
  24. Java verify void method calls n times with Mockito
  25. Powermock – java.lang.IllegalStateException: Failed to transform class
  26. Why are my mocked methods not called when executing a unit test?
  27. Integration tests for AspectJ
  28. Time dependent unit tests
  29. How do I ignore certain elements when comparing XML?
  30. How to define a JUnit method rule in a test suite?

Leave a Comment