1. Introduction
@MockBean is an annotation provided by the Spring framework. It helps create a mock object of a Spring bean, allowing us to replace the actual bean with a mock during testing. This is particularly helpful during integration testing, where we want to isolate certain components without relying on their actual implementations.
In this tutorial, we’ll look into various ways to configure @MockBean components to test Spring Boot applications.
2. The Need for Early Configuration
Configuring the @MockBean component before the application starts is crucial when we need to control the behavior of certain beans in an application during testing, especially if these beans interact with external systems like databases or web services.
Benefits of early configuration:
- Isolate tests: It helps isolate the behavior of the unit under test by mocking its dependencies
- Avoid external calls: It prevents calls to external systems, like databases or external APIs, that would otherwise be called by original beans
- Control bean behavior: We can predefine the responses and behavior of mocked beans, which ensures the tests are predictable and not dependent on external factors
3. Techniques for Early Configuration
We’ll first examine how to configure the @MockBean components and then explore various methods for configuring these components before the application startup.
3.1. Direct Declaration in Test Class
This is the simplest way to mock a bean. We can use @MockBean annotation directly on the field in the test class. Spring Boot automatically replaces the actual bean with the mocked bean in the context:
@SpringBootTest(classes = ConfigureMockBeanApplication.class)
public class DirectMockBeanConfigUnitTest {
@MockBean
private UserService mockUserService;
@Autowired
private UserController userController;
@Test
void whenDirectMockBean_thenReturnUserName(){
when(mockUserService.getUserName(1L)).thenReturn("John Doe");
assertEquals("John Doe", userController.getUserName(1L));
verify(mockUserService).getUserName(1L);
}
}
In this approach, the mock seamlessly replaces the real bean in the Spring context, allowing other beans that depend on it to use the mock. We can independently define and control the mock without affecting other tests.
3.2. Configuring @MockBean Using @BeforeEach
We can configure mock beans using Mockito within a @BeforeEach method, ensuring they are available before the test starts.
It’s useful when we want to mock certain beans at a higher level, such as repositories, services, or controllers – that aren’t directly testable or have complex dependencies.
In integration tests, where components often rely on each other, @MockBean with @BeforeEach helps create a controlled environment by isolating certain components and mocking their dependencies at the start of each test, allowing us to focus on the functionality being tested:
@SpringBootTest(classes = ConfigureMockBeanApplication.class)
public class ConfigureBeforeEachTestUnitTest {
@MockBean
private UserService mockUserService;
@Autowired
private UserController userController;
@BeforeEach
void setUp() {
when(mockUserService.getUserName(1L)).thenReturn("John Doe");
}
@Test
void whenParentContextConfigMockBean_thenReturnUserName(){
assertEquals("John Doe", userController.getUserName(1L));
verify(mockUserService).getUserName(1L);
}
}
This approach ensures that our mock configuration is reset before each test, making it useful for isolated testing.
3.3. Using @Mockbean in a Nested Test Configuration Class
To make test classes cleaner and to reuse mock configurations, we can move the mock setup to a separate nested configuration class. We need to annotate the configuration class with @TestConfiguration. In this class, we instantiate and configure mocks:
@SpringBootTest(classes = ConfigureMockBeanApplication.class)
@Import(InternalConfigMockBeanUnitTest.TestConfig.class)
public class InternalConfigMockBeanUnitTest {
@TestConfiguration
static class TestConfig {
@MockBean
UserService userService;
@PostConstruct
public void initMock(){
when(userService.getUserName(3L)).thenReturn("Bob Johnson");
}
}
@Autowired
private UserService userService;
@Autowired
private UserController userController;
@Test
void whenConfiguredUserService_thenReturnUserName(){
assertEquals("Bob Johnson", userController.getUserName(3L));
verify(userService).getUserName(3L);
}
}
This approach helps test classes focused on tests, with configurations separate, which makes it easier to manage complex configurations.
3.4. Using @Mockbean in an External Test Configuration Class
When we need to reuse test configurations across multiple test classes, we can externalize test configurations to a separate class. Similarly to the previous approach, we need to annotate the configuration class with @TestConfiguration. It allows us to create a separate test-specific configuration class that can be used to mock or replace beans within the Spring context:
@TestConfiguration
class TestConfig {
@MockBean
UserService userService;
@PostConstruct
public void initMock(){
when(userService.getUserName(2L)).thenReturn("Jane Smith");
}
}
We can import this test configuration in our test class using @Import(TestConfig.class):
@SpringBootTest(classes = ConfigureMockBeanApplication.class)
@Import(TestConfig.class)
class ConfigureMockBeanApplicationUnitTest {
@Autowired
private UserService mockUserService;
@Autowired
private UserController userController;
@Test
void whenConfiguredUserService_thenReturnUserName(){
assertEquals("Jane Smith", userController.getUserName(2L));
verify(mockUserService).getUserName(2L);
}
}
This approach is beneficial when we need to configure multiple test components or want to have reusable mock setups that can be shared across different test cases.
3.5. Profile-Specific Configuration
When we need to test for different profiles, such as different environments (e.g., dev or test), we can create profile-specific configurations. By applying @ActiveProfiles to our test class, we can load different application configurations for our testing needs.
Let’s create a test configuration for our dev profile:
@Configuration
@Profile("Dev")
class DevProfileTestConfig {
@MockBean
UserService userService;
@PostConstruct
public void initMock(){
when(userService.getUserName(4L)).thenReturn("Alice Brown");
}
}
Then, we can set the active profile as “Dev” in our test class:
@SpringBootTest(classes = ConfigureMockBeanApplication.class)
@ActiveProfiles("Dev")
public class ProfileBasedMockBeanConfigUnitTest {
@Autowired
private UserService userService;
@Autowired
private UserController userController;
@Test
void whenDevProfileActive_thenReturnUserName(){
assertEquals("Alice Brown", userController.getUserName(4L));
verify(userService).getUserName(4L);
}
}
This approach is useful when testing in different environments like development, test, or production, ensuring we simulate the exact conditions needed for a specific profile.
3.6. Using Mockito’s Answer for Dynamic Mocks
When we want more control over mock behavior, such as dynamically changing the response based on input or other conditions at runtime, we can utilize Mockito’s Answer Interface. This allows us to configure dynamic mock behavior before the test starts:
@SpringBootTest(classes = ConfigureMockBeanApplication.class)
public class MockBeanAnswersUnitTest {
@MockBean
private UserService mockUserService;
@Autowired
private UserController userController;
@BeforeEach
void setUp() {
when(mockUserService.getUserName(anyLong())).thenAnswer(invocation ->{
Long input = invocation.getArgument(0);
if(input == 1L)
return "John Doe";
else if(input == 2L)
return "Jane Smith";
else
return "Bob Johnson";
});
}
@Test
void whenDirectMockBean_thenReturnUserName(){
assertEquals("John Doe", mockUserService.getUserName(1L));
assertEquals("Jane Smith", mockUserService.getUserName(2L));
assertEquals("Bob Johnson", mockUserService.getUserName(3L));
verify(mockUserService).getUserName(1L);
verify(mockUserService).getUserName(2L);
verify(mockUserService).getUserName(3L);
}
}
In this example, we configured dynamic response based on the method invocation, giving us more flexibility in complex test scenarios.
4. Testing Strategies and Considerations
- Avoid mocking too much: excessive use of @MockBean can reduce the effectiveness of our tests. Ideally, we should limit the use of mocks to those dependencies that are truly external or difficult to control (e.g., external APIs and databases).
- Use @TestConfiguration for complex setup: when we need to configure more complex behavior, we should use @TestConfiguration, as this allows us to set up mocks more elegantly and provides better support for advanced configurations.
- Verify interactions: besides setting up return values, it’s also crucial to verify interactions with mocks. This ensures that the correct methods are called as expected.
5. Conclusion
Configuring @MockBean components before the application starts can be a valuable strategy in testing Spring Boot applications as this allows us to fine-tune control over mocked dependencies.
In this article, we learned various ways to configure mock bean components. By following the approach needed for our test and applying best practices and testing strategies, we can effectively isolate components and validate behavior in a controlled environment.
As always, all code snippets used in this article are available over on GitHub.