Dev/prod parity : Spring Boot Testcontainers

Introduction

Dev/prod parity aims to reduce the gap between development and production environments. This article targets the tools gap, especially in integration testing with Spring Testcontainers, as a way to make development and production as similar as possible.
When conducting integration tests involving databases, we must manage all CRUD operations carefully. This is crucial in a centralized database environment where a Test, such as TestDeleteUserByID_ShouldReturnOk(), might ‘accidentally’ decide to wipe out the account of our most faithful client who’s been with us since 2015 🤦‍♂️
To mitigate such risks, we can consider solutions like database transactions to isolate test data. For example, a test could start a transaction to modify data and then roll back at the end, thereby leaving the database in its original state.
However, this raises a critical issue: WHAT TESTS THE TEST ?

What if the isolation fails and the code executes changes that are somehow not rolled back, leading to data leaks into the production environment? The potential damage in such scenarios is significant.

Alternatively, self-contained testing with an in-memory database like H2DB presents also some challenges. even if it's easy to set up, H2DB differs from RDBMS so there is a high probability that tests might have different results between development and production environments, so we can't trust those results.

https://stackoverflow.com/questions/62778900/syntax-error-h2-database-in-postgresql-compatibility

The next less problematic solution is to clone the database, providing a less risky approach with a production-like environment. However, this method comes with its limits. Given that ORMs automate the creation and setup of the production database schema, we need to think about how to keep the cloned development database in sync.

---

Test Anything You Can Containerize: Database, Message Broker, And More

"Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container."

Originally developed for Java, it has since been expanded to support other languages like Go, Rust, and .NET.

The main idea of Testcontainers is to provide an on-demand infrastructure, runnable from the IDE, where tests can be conducted without the need for mocking or using in-memory services, and with automatic cleanup.

We can achieve this in three steps :

• Start the required services and prepare the infrastructure by setting up Docker containers and configure your application to use this setup as the testing infrastructure.
• Run your tests on the dockerized infrastructure.
• Automatically clean up the dockerized infrastructure once the tests have concluded

Testcontainers library documentation

---

Spring Boot Testcontainers Implementation

In ApplicationIntegrationTests, which is the base class for integration testing, we define a static PostgreSQLContainer. This container is used across all test instances derived from this class.

The @Testcontainers annotation enables the discovery of all fields annotated with @Container, managing their container lifecycle methods, and starting the containers.

• Containers declared as static fields are shared between test methods. They are started only once before any test method is executed and stopped after the last test method has executed.
• Containers declared as instance fields are started and stopped for every test method.

The @DynamicPropertySource annotation allows us to dynamically inject properties into our test environment.

@Testcontainers
@ActiveProfiles("test")
public abstract class ApplicationIntegrationTests {
    @Container
    protected static PostgreSQLContainer<?> postgres=new PostgreSQLContainer<>("postgres:17.2-alpine")
            .withDatabaseName("testcontainersproject")
            .withUsername("root")
            .withPassword("root");

    @DynamicPropertySource
    static void initialize(DynamicPropertyRegistry registry)
    {
        registry.add("spring.datasource.url",postgres::getJdbcUrl);
        registry.add("spring.datasource.username",postgres::getUsername);
        registry.add("spring.datasource.password",postgres::getPassword);
    }


}

Alternatively, we can skip the use of @Testcontainers and @Container and instead manage the container lifecycle directly using @BeforeAll and @AfterAll. This approach allows more control over when and how containers are started and stopped

@BeforeAll
public static void runContainer(){
        postgres.start();
}
@AfterAll
static void stopContainers() {
    postgres.stop();
}

In the @AfterAll callback method, we explicitly stop the Postgres container. However, even if we don't explicitly stop the container, Testcontainers will automatically clean up and shut down the containers at the end of the test run.

Now we can create integration tests by extending ApplicationIntegrationTests as follows.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class CategoryControllerTest extends ApplicationIntegrationTests {
    private static final String CATEGORY_ENDPOINT="/categories";
   @Autowired
    private MockMvc mockMvc;
    @Autowired
    private CategoryRepository categoryRepository;

    @Test
    void TestGetAllCategories_ShouldReturnOk() throws Exception {

        List<Category> categories = List.of(
                new Category("Electronics", "All kinds of electronic gadgets from smartphones to laptops"),
                new Category("Books", "A wide range of books from novels to educational textbooks")
        );
        categoryRepository.saveAll(categories);
        MvcResult mvcResult=mockMvc.perform(
                get(CATEGORY_ENDPOINT).
                        contentType(MediaType.APPLICATION_JSON)
        )
                .andExpect(status().isOk())
                .andReturn();
        var response=mvcResult.getResponse().getContentAsString();
        assertNotNull(response);
        assertFalse(response.isEmpty());
    }
}