1. Overview
JUnit is one of the most popular unit testing frameworks available in Java. Moreover, Spring Boot provides it as a default test dependency for its applications.
In this tutorial, we’ll compare two JUnit runners – SpringRunner and MockitoJUnitRunner. We’ll understand their purpose and the key differences between them.
2. @RunWith vs @ExtendWith
Before we go further, let’s recap how we can extend basic JUnit functionality or integrate it with other libraries.
JUnit 4 allows us to implement custom Runner classes responsible for running tests by applying extra functionalities. To invoke a custom runner, we annotate a test class using a @RunWith annotation:
@RunWith(CustomRunner.class)
class JUnit4Test {
// ...
}
As we know, JUnit 4 is now in a legacy state, succeeded by JUnit 5. The newer version brings us a completely new engine with a rewritten API. It also changes the concept of the extension model. Instead of implementing custom Runner or Rule classes, we can now use the Extension API with an @ExtendWith annotation:
@ExtendWith(CustomExtensionOne.class)
@ExtendWith(CustomExtensionTwo.class)
class JUnit5Test {
// ...
}
Unlike the previous runner model, we can provide multiple extensions to a single class. Most of the previously delivered runners were also rewritten for their extension counterparts.
3. Spring Example Application
For better understanding, let’s introduce a simple Spring Boot application – a converter that maps the given strings to uppercase.
Let’s start with the implementation of the data provider:
@Component
public class DataProvider {
private final List<String> memory = List.of("baeldung", "java", "dummy");
public Stream<String> getValues() {
return memory.stream();
}
}
We’ve just created a Spring Component with hardcoded string values. Moreover, it provides a single method to stream these strings.
Secondly, let’s implement a service class that transforms our values:
@Service
public class StringConverter {
private final DataProvider dataProvider;
@Autowired
public StringConverter(DataProvider dataProvider) {
this.dataProvider = dataProvider;
}
public List<String> convert() {
return dataProvider.getValues().map(String::toUpperCase).toList();
}
}
It’s a simple bean that fetches data from the previously created DataProvider and applies uppercase mapping.
Now, we can use our application to create JUnit tests. We’ll see the difference between SpringRunner and MockitoJUnitRunner classes.
4. MockitoJUnitRunner
As we know, Mockito is a mocking framework that’s used in conjunction with other testing frameworks to return dummy data and avoid external dependencies. This library provides us MockitoJUnitRunner – a dedicated JUnit 4 runner to integrate Mockito and take advantage of the library’s capabilities.
Let’s now create the first test for StringConverter:
public class StringConverterTest {
@Mock
private DataProvider dataProvider;
@InjectMocks
private StringConverter stringConverter;
@Test
public void givenStrings_whenConvert_thenReturnUpperCase() {
Mockito.when(dataProvider.getValues()).thenReturn(Stream.of("first", "second"));
val result = stringConverter.convert();
Assertions.assertThat(result).contains("FIRST", "SECOND");
}
}
We’ve just mocked our DataProvider to return two strings. But if we run it, the test fails:
java.lang.NullPointerException: Cannot invoke "DataProvider.getValues()" because "this.dataProvider" is null
That is because our mock isn’t properly initialized. The @Mock and @InjectMocks annotations currently do nothing. We can fix this by implementing the init() method:
@Before
public void init() {
MockitoAnnotations.openMocks(this);
}
If we don’t want to use annotations, we can also create and inject mocks programmatically:
@Before
public void init() {
dataProvider = Mockito.mock(DataProvider.class);
stringConverter = new StringConverter(dataProvider);
}
We’ve just initialized mocks programmatically using the Mockito API. Now, the test works as expected and our assertions succeed.
Next, let’s go back to our first version, remove the init() method, and annotate the class using the MockitoJUnitRunner:
@RunWith(MockitoJUnitRunner.class)
public class StringConverterTest {
// ...
}
Again, the test succeeds. We invoked a custom runner, which took responsibility for managing our mocks. We didn’t have to initialize them manually.
To summarize, MockitoJUnitRunner is a dedicated runner for the Mockito framework. It’s responsible for initializing @Mock, @Spy, and @InjectMock annotations, so that explicit usage of MockitoAnnotations.openMocks() is not necessary. Moreover, it detects unused stubs in the test and validates mock usage after each test method, just like Mockito.validateMockitoUsage() does.
We should remember that all runners are originally designed for JUnit 4. If we want to support Mockito annotations with JUnit 5, we can use MockitoExtension:
@ExtendWith(MockitoExtension.class)
public class StringConverterTest {
// ...
}
This extension ports the functionalities from the MockitoJUnitRunner into the new extension model.
5. SpringRunner
If we analyze our test more deeply, we’ll see that, despite using Spring, we don’t start a Spring Container at all. Let’s now try to modify our example and initialize a Spring Context.
First, instead of MockitoJUnitRunner, let’s just replace it with the SpringRunner class and check the results:
@RunWith(SpringRunner.class)
public class StringConverterTest {
// ...
}
As before, the test succeeds and the mocks are properly initialized. Moreover, a Spring Context is also started. We can conclude that SpringRunner not only enables Mockito annotations, just like MockitoJUnitRunner does, but also initializes a Spring Context.
Of course, we haven’t seen Spring’s full potential yet in our test. Instead of constructing new objects, we can inject them as Spring beans. As we know, the Spring test module has the Mockito integration by default, which also provides us the @MockBean and @SpyBean annotations – integrating mocks and beans features together.
Let’s rewrite our test:
@ContextConfiguration(classes = StringConverter.class)
@RunWith(SpringRunner.class)
public class StringConverterTest {
@MockBean
private DataProvider dataProvider;
@Autowired
private StringConverter stringConverter;
// ...
}
We just replaced the @Mock annotation with @MockBean next to the DataProvider object. It’s still a mock, but can now also be used as a bean. We also configured our Spring Context via the @ContextConfiguration class annotation and injected StringConverter. As a result, the test still succeeds, but it now uses Spring beans and Mockito together.
To sum up, SpringRunner is a custom runner created for JUnit 4 that provides the functionality of the Spring TestContext Framework. Since Mockito is the default mocking framework integrated with the Spring stack, the runner brings full support provided by MockitoJUnitRunner. Sometimes, we may also come across SpringJUnit4ClassRunner, which is an alias, and we can use both alternately.
If we’re looking for an extension counterpart for the SpringRunner, we should use SpringExtension:
@ExtendWith(SpringExtension.class)
public class StringConverterTest {
// ...
}
As JUnit 5 is the default testing framework in the Spring Boot stack, the extension has been integrated with many test slice annotations, including @SpringBootTest.
6. Conclusion
In this article, we learned the difference between SpringRunner and MockitoJUnitRunner.
We started with a recap of the extension model used in JUnit 4 and JUnit 5. JUnit 4 uses dedicated runners while JUnit 5 supports extensions. At the same time, we can provide a single runner or multiple extensions.
Then, we looked at MockitoJUnitRunner, which enables the Mockito framework to be supported in our JUnit 4 tests. In general, we can configure our mocks via dedicated @Mock, @Spy, and @InjectMocks annotations without any initialization methods.
Finally, we discussed SpringRunner, which releases all the advantages of cooperation between the Mockito and Spring frameworks. It not only supports the basic Mockito annotations but also enables Spring ones: @MockBean and @SpyBean. The mocks constructed in this way can be injected using the Spring Context.
As always, the full implementation of these examples can be found over on GitHub.
