Mockito, JUnit and Spring

by

Honestly I am not sure if I really understand your question 😛 I will try to clarify as much as I can, from what I get from your original question:

First, in most case, you should NOT have any concern on Spring. You rarely need to have spring involved in writing your unit test. In normal case, you only need to instantiate the system under test (SUT, the target to be tested) in your unit test, and inject dependencies of SUT in the test too. The dependencies are usually a mock/stub.

Your original suggested way, and example 2, 3 is precisely doing what I am describing above.

In some rare case (like, integration tests, or some special unit tests), you need to create a Spring app context, and get your SUT from the app context. In such case, I believe you can:

1) Create your SUT in spring app ctx, get reference to it, and inject mocks to it

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("test-app-ctx.xml")
public class FooTest {

    @Autowired
    @InjectMocks
    TestTarget sut;

    @Mock
    Foo mockFoo;

    @Before
    /* Initialized mocks */
    public void setup() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void someTest() {
         // ....
    }
}

or

2) follow the way described in your link Spring Integration Tests, Creating Mock Objects. This approach is to create mocks in Spring’s app context, and you can get the mock object from the app ctx to do your stubbing/verification:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("test-app-ctx.xml")
public class FooTest {

    @Autowired
    TestTarget sut;

    @Autowired
    Foo mockFoo;

    @Test
    public void someTest() {
         // ....
    }
}

Both ways should work. The main difference is the former case will have the dependencies injected after going through spring’s lifecycle etc. (e.g. bean initialization), while the latter case is injected beforehands. For example, if your SUT implements spring’s InitializingBean, and the initialization routine involves the dependencies, you will see the difference between these two approach. I believe there is no right or wrong for these 2 approaches, as long as you know what you are doing.

Just a supplement, @Mock, @Inject, MocktoJunitRunner etc are all unnecessary in using Mockito. They are just utilities to save you typing the Mockito.mock(Foo.class) and bunch of setter invocations.

More Related Contents:

  1. Mocking static methods with Mockito
  2. How to mock void methods with Mockito
  3. Difference between @Mock and @InjectMocks
  4. Mockito – difference between doReturn() and when()
  5. Test class with a new() call in it with Mockito
  6. Difference between @Mock, @MockBean and Mockito.mock()
  7. Final method mocking
  8. How to use Mockito with JUnit5
  9. Mockito : how to verify method was called on an object created within a method?
  10. How to tell a Mockito mock object to return something different the next time it is called?
  11. Mockito: InvalidUseOfMatchersException
  12. How to use ArgumentCaptor for stubbing?
  13. Unit testing with mockito for constructors
  14. How to mock new Date() in java using Mockito
  15. Mockito – @Spy vs @Mock
  16. Mockito verify order / sequence of method calls
  17. Unit testing with Spring Security
  18. How to verify that a specific method was not called using Mockito?
  19. Mock final class with Mockito 2
  20. Mockito: Inject real objects into private @Autowired fields
  21. Spring @ContextConfiguration how to put the right location for the xml
  22. Why are my mocked methods not calld when executing a unit test?
  23. Forming Mockito “grammars”
  24. What’s the difference between Mockito Matchers isA, any, eq, and same?
  25. Testing @Scheduled in spring
  26. How to mock RestTemplate in Java Spring?
  27. Java verify void method calls n times with Mockito
  28. Can Mockito verify parameters based on their values at the time of method call?
  29. Why are my mocked methods not called when executing a unit test?
  30. How to mock a builder with mockito

Leave a Comment