CODEWITHSUNDEEP
springjunit4cucumber-javatestcontainerscucumber-junit
Hk0
Hk0

Reputation: 3

Start a Testcontainers container during each fresh application context (@DirtiesContext), with injection of properties (@DynamicPropertySource)

I am using Testcontainers to execute integration tests in a Spring project. I am using JUnit 4.x and Cucumber 7.4.1.

I want to start a docker-compose.yml-based set of containers before each test, as that makes it easy to start from scratch. Hence, I am using @DirtiesContext.

The challenge here is that certain application properties, such as spring.rabbitmq.host, are needed before the actual application context can start. So I need to inject them beforehand. There is @DynamicPropertySource for that. But then I also need to get access to my context-scoped docker containers. The best I came up with so far is the following:

@CucumberContextConfiguration
@SpringBootTest(classes = TestConfig.class)
@DirtiesContext
public class CucumberITConfig {
    @DynamicPropertySource
    private static void properties(DynamicPropertyRegistry registry) {
        DockerComposeContainer container = new DockerComposeContainer(new File("docker-compose.yml"))
                .withExposedService("rabbitmq", 5672);

        container.start();
        registry.add("spring.rabbitmq.host", () -> container.getServiceHost("rabbitmq", 5672));
    }
}

This constructs new docker containers locally and waits for the host to be passed to the registry. While this seem to work, this looks more like a hackish approach to me. Also, a problem here is that the containers stack up after each test. That is, in the 7th test, for example, the containers from all previous 6 cycles are still running.

Are there better approaches to start Testcontainers-based docker containers before each application context, while also being able to destruct them afterwards?

Upvotes: 0

Views: 1929

Answers (1)

Kevin Wittek
Kevin Wittek

Reputation: 1572

If you are using @DirtiesContext after all, you can set these values as System properties and omit @DynamicPropertySource altogether. However, as others have pointed out, solving test pollution by re-creating the Spring context and all dependent services for every test class will be very slow and is generally considered an anti-pattern.

Upvotes: 1

Related Questions