Configuring @MockBean Components Before Application Start

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.