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.
"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 :
Testcontainers library documentation
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.
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()); } }
The above is the detailed content of Dev/prod parity : Spring Boot Testcontainers. For more information, please follow other related articles on the PHP Chinese website!