Make use of @DynamicPropertySource in our integration tests

[wilkinsona]

There's a bit of ceremony involved at the moment:

@Testcontainers
@ContextConfiguration(initializers = DataRedisTestIntegrationTests.Initializer.class)
@DataRedisTest
public class DataRedisTestIntegrationTests {

    @Container
    public static RedisContainer redis = new RedisContainer();

    // …

    static class Initializer
            implements ApplicationContextInitializer<ConfigurableApplicationContext> {

        @Override
        public void initialize(
                ConfigurableApplicationContext configurableApplicationContext) {
            TestPropertyValues.of("spring.redis.port=" + redis.getMappedPort())
                    .applyTo(configurableApplicationContext.getEnvironment());
        }

    }

It would be nice to be able to do something like this instead:

@Testcontainers
@DataRedisTest
public class DataRedisTestIntegrationTests {

    @Container
    @MapPortToProperty("spring.redis.port")
    public static RedisContainer redis = new RedisContainer();

A few thoughts:

• The examples above are JUnit 5. We'd need to consider JUnit 4 as well
• The lifecycle ordering will need to be right so that the container's port is available before the context refreshes
• Setting the port will affect context caching

/cc @bsideup

[bsideup]

@wilkinsona
Take a look at https://github.com/Playtika/testcontainers-spring-boot

Also, there are a few things to consider covering:

• it is very important to also map the host, not just port. It is "localhost" only in ~60% cases
• some containers provide convenient methods like KafkaContainer#getBootstrapServers, perhaps we can use a SpEL expression or something

BTW I have a bit crazy idea:
What if Spring Boot implements something like:

@Testcontainers
@DataRedisTest
public class DataRedisTestIntegrationTests {

    @Container
    public static RedisContainer redis = new RedisContainer();

    @PropertyContributor
    static Callable<PropertySource> propertySource = () -> {
        return TestPropertyValues.of(
            "spring.redis.host=" + redis.getContainerIpAddress(),
            "spring.redis.port=" + redis.getMappedPort()
        );
    }

This way it can source properties from anywhere, including Testcontainers. WDYT?

[antkorwin]

Hi, I think I solved this in my library (here: https://github.com/jupiter-tools/spring-test-redis), maybe it can help you:

@SpringBootTest
@RedisTestContainer
class RedisTestContainerTest {

    @Autowired
    private RedisTemplate redisTemplate;

    @Test
    void readWriteValueByRedisTemplate() {
        String key = "test";
        String value = "sabracadabra";
        // Act
        redisTemplate.opsForValue().set(key, value);
        // Assert
        assertThat(redisTemplate.opsForValue().get(key)).isEqualTo(value);
    }
}

this code run Redis test container and bind it to default spring boot properties (spring.redis.host / spring.redis.port)

I use my own ContextCustomizer, it provides an ability to start multiple containers and avoids problems with context caching in tests. Also, it provides independence on the test engine (you can use JUnit4 and JUnit5)

Example of executing multiple containers in the one test case:

@SpringBootTest
@RedisTestContainer 
@RedisTestContainer(hostTargetProperty = "second.redis.host", portTargetProperty = "second.redis.port")
@RedisTestContainer(hostTargetProperty = "third.redis.host", portTargetProperty = "third.redis.port") 
class MultipleContainerInOneTest {
    ...
}

the second container set host/port value in the specified properties, after start application context.

Maybe we can use it as part of the spring boot? I am ready to make a PR here.

[wilkinsona]

Thanks for the offer, @antkorwin, but that's not quite what we're looking for here. The use of Redis was just an example and my goal is to provide something that works for any container that's being managed by Testcontainers. That would be something along the lines of the general purpose annotation in my opening description or the property contributor imagined by @bsideup.

[nosan]

I have a slightly different approach. Please take a look https://github.com/nosan/spring-boot/commits/map-to-property This branch introduces @MapToProperty annotation. This annotation can be applied only to static fields.

Here is a quick example of how this annotation can be used:

class DataRedisTests {

	
// (2) Suppliers	
	@Container
	static final RedisContainer redis = new RedisContainer();
	@MapToProperty("spring.redis.host")
	static final Supplier<String> host  = redis::getContainerIpAddress;
	@MapToProperty("spring.redis.port")
	static final Supplier<Integer> REDIS_PORT_SUPPLIER = redis::getFirstMappedPort;
	
// (3) Constants	
	@MapToProperty( "spring.redis.port")
	static final int port = 6379;
// (4) Map
	@MapToProperty("spring.redis")
	static final Supplier<Map<String, Object>> properties = () -> {
		Map<String, Object> source = new LinkedHashMap<>();
		source.put("host", redis.getContainerIpAddress());
		source.put("port", redis.getFirstMappedPort());
		return source;
	};
}

Please let me know what you think.

[philwebb]

The low level property mapping support is quite nice, but I can't help feeling that we should be able to apply these conventions automatically. I wonder if we can provide some pre-supplied mapping conventions that detect well known containers and map them to well known Spring Boot properties.

In other words, can we make it so that this lone will get you spring.redis.host and spring.redis.port properties:

@Testcontainers
@DataRedisTest
public class DataRedisTestIntegrationTests {

    @Container
    public static RedisContainer redis = new RedisContainer();

[wilkinsona]

That feels a little bit too magic to me.