DynamicPropertySource is getting initialized way too late in the startup for 'config.import'

[edudar]

I have ConfigData implementation for a custom KV storage: Loader, LocationResolver, Resource. They are specified in spring.factories under appropriate sections. I also verified that the whole setup works fine when using in an application.

I want to test it though. I use @SpringBootTest for the test and Testcontainers for KV storage setup. @DynamicPropertySource is there quite specifically to address the dynamic nature of ports and other options exposed by Testcontainers so this is what I do:

@Testcontainers
@SpringBootTest(classes = ..., webEnvironment = NONE)
class KVTest {
  @DynamicPropertySource
  static void kvProperties(registry) {
    registry.add("spring.config.import", () -> "kv:" + getConnectionString());
  }
}

When I run the test, I do see that Loader is being created but when ConfigDataEnvironment processes and applies itself, @DynamicPropertySource has not been taken into account yet. Inlined Test Properties are already there but they are not dynamic. As result, anything that might have been added to properties for ConfigData is getting in way too late.

[wilkinsona]

Unfortunately, I don't think there's anything we can do about this, at least not in Spring Boot. The point in the lifecycle at which @DynamicPropertySource is processed is determined by Spring Framework.

To test your custom config data implementation, I'd recommend using SpringApplication in a "standard" test method rather than using @SpringBootTest. There are some examples of that in Boot's own tests for config-related code. See ConfigFileApplicationListenerLegacyReproTests, for example.

[edudar]

@wilkinsona but does this sound like something reasonable to ask? Wondering if I should bring this up with the Spring F team then.

[wilkinsona]

It certainly wouldn't be unreasonable to ask, but I'd be surprised if it is something that the Framework team will change. The test framework is designed for integration testing an application context (or context hierarchy) so it's not really the right tool for the job of testing lower-level infrastructure of SpringApplication. As I said above, calling SpringApplication directly in your test method is a better approach.