Testing with JUnit, Mockito, and Testcontainers

1. Unit Testing: The Foundation of Quality

Unit tests are the bedrock of a solid testing strategy. They are fast, focused, and verify that a single class or method behaves correctly without relying on external systems like databases or network calls. To achieve this isolation, we use "mocks."

For this, the standard toolkit in the Java ecosystem is JUnit 5 (the testing framework) and Mockito (the mocking library).

Key Concepts & Tools

• JUnit 5: Provides the test runner and assertion library (e.g., assertEquals). Key annotations include @Test, @BeforeEach, @AfterEach.
• Mockito: Allows you to create "mock" objects that simulate the behavior of real dependencies. This lets you test a class in isolation. Key annotations and methods include:
  • @Mock: Creates a mock implementation for a class or interface.
  • @InjectMocks: Creates an instance of the class you want to test and injects the mocks (created with @Mock) into it.
  • when(...).thenReturn(...): Defines the behavior of a mock object's method.
  • verify(...): Checks if a mock object's method was called with specific arguments.

The Arrange-Act-Assert Pattern

As you saw in the article, a clean unit test follows the Arrange-Act-Assert pattern (also known as Given-When-Then in BDD style):

1. Arrange (Given): Set up the test. This includes creating mock objects, defining their behavior with when(), and preparing any input data.
2. Act (When): Execute the method you are testing.
3. Assert (Then): Verify the outcome. This involves checking the return value of the method (assertEquals) and/or verifying that your code interacted correctly with its dependencies (verify).

Let's solidify this with an example based on the article's UserService.

@ExtendWith(MockitoExtension.class) // Enables Mockito annotations
class UserServiceTest {

    @Mock // Create a mock UserRepository
    private UserRepository userRepository;

    @InjectMocks // Create a UserService and inject the mock userRepository
    private UserService userService;

    @Test
    void shouldReturnUserNameWhenUserExists() {
        // Arrange
        User user = new User(1L, "Alice");
        // Define mock behavior: when findById(1L) is called, return our user
        when(userRepository.findById(1L)).thenReturn(Optional.of(user));

        // Act
        String userName = userService.getUserName(1L);

        // Assert
        assertEquals("Alice", userName); // Check the result
        verify(userRepository).findById(1L); // Verify the repository was called
    }

    @Test
    void shouldThrowExceptionWhenUserNotFound() {
        // Arrange
        // Define mock behavior: when findById is called with any Long, return empty
        when(userRepository.findById(anyLong())).thenReturn(Optional.empty());

        // Act & Assert
        // Check that calling the method throws the expected exception
        assertThrows(RuntimeException.class, () -> {
            userService.getUserName(99L);
        });
    }
}

2. Integration Testing: Verifying Collaboration

While unit tests are essential, they can't tell you if your components work together correctly within the Spring framework. For example:

• Does your @RestController correctly deserialize JSON and call your @Service?
• Does your @Repository correctly execute a query against a database?

This is where integration tests come in. They load a part of, or all of, your Spring application context to test the interaction between components.

Test Slices vs. Full Context

Spring Boot offers two main approaches:

1. Test Slices (@WebMvcTest, @DataJpaTest): These are lightweight integration tests that load only a specific "slice" of the application context. For example, @WebMvcTest loads the web layer (controllers, filters, etc.) but mocks the service layer. This is faster and more focused.
2. Full Context (@SpringBootTest): This loads the entire application context, just like running the real application. It's slower but provides the highest confidence that everything is wired correctly.

3. High-Fidelity Integration Testing with Testcontainers

Using an in-memory database like H2 for @DataJpaTest is fast, but it has a significant drawback: H2 is not PostgreSQL (or MySQL, or Oracle). Subtle differences in SQL dialects, transaction handling, or available functions can lead to tests that pass locally but fail in production.

Testcontainers solves this problem by bringing the power of Docker to your tests. It allows you to programmatically start, use, and stop lightweight, disposable Docker containers for any service you need—databases, message brokers, caches, etc.

This means you can run your integration tests against a real PostgreSQL database, giving you extremely high confidence that your persistence layer will work as expected in a production environment.

There are two primary ways to integrate Testcontainers with Spring Boot:

1. @DynamicPropertySource: The traditional way. You declare a container, and then write a static method to dynamically get the JDBC URL, username, and password from the running container and set them as Spring properties.
2. @ServiceConnection (Spring Boot 3.1+): A modern, cleaner approach. You simply add this annotation to your container declaration, and Spring Boot automatically configures the connection for you. Using this shows you are up-to-date with the latest best practices.

Now, let's look at the official documentation to see the different integration styles, including the cleaner @ServiceConnection.

Here's a complete example using @SpringBootTest and the modern @ServiceConnection approach, which is the preferred method for new applications:

// You need the spring-boot-testcontainers and testcontainers-postgresql dependencies
// in your build.gradle or pom.xml

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE)
@Testcontainers // Activates Testcontainers support for JUnit 5
class UserRepositoryIntegrationTest {

    @Container // Manages the lifecycle of the container
    @ServiceConnection // Automatically configures the datasource properties
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15-alpine");
    
    @Autowired
    private UserRepository userRepository;

    @Test
    void connectionEstablished() {
        // A simple test to confirm the container started and is reachable
        assertTrue(postgres.isCreated());
        assertTrue(postgres.isRunning());
    }

    @Test
    void shouldSaveAndFindUserByEmail() {
        // Arrange
        User user = new User(null, "test@example.com", "Test User");
        
        // Act
        userRepository.save(user);
        
        // Assert
        Optional<User> foundUser = userRepository.findByEmail("test@example.com");
        
        assertTrue(foundUser.isPresent());
        assertEquals("Test User", foundUser.get().getName());
    }
}

Conclusion

You have now learned the fundamentals of building a multi-layered testing strategy for a Spring Boot application. This is a critical skill set that separates junior developers from senior engineers who are trusted to build and deploy reliable software.

Key Takeaways:

• Unit Tests (JUnit & Mockito): Use them to test business logic in isolation. They are fast and form the base of your testing pyramid. ArgumentCaptor is a key tool for verifying interactions with void methods.
• Integration Tests (@SpringBootTest, Slices): Use them to verify that your Spring components are correctly configured and interact with each other as expected. Test slices like @WebMvcTest offer a faster, more focused alternative.
• Testcontainers: Elevate your integration tests by using real services (like PostgreSQL, Kafka, Redis) in Docker containers. This eliminates the gap between your test and production environments. Prefer the modern @ServiceConnection annotation where possible.

Preview of the Next Lesson:
We've covered testing the service and data layers. Next, we'll zoom in on the API layer. In the next lesson, "Implement REST API tests using MockMvc or REST Assured," we will dive deeper into writing comprehensive and maintainable tests for your REST controllers, ensuring your API contracts are stable and reliable.