Expected behavior is that a multi-document properties file can be created with different sections separated by "#--- " characters, for each section applicable to a given active profile. This works as expected when using a file named application.properties and allowing Spring Boot to bootstrap the application normally.
However, if the default application properties file is overridden in a JUnit test class annotated with a test property source (e.g. @TestPropertySource(locations="classpath:test.properties")), Spring Boot ignores the active profiles and simply references the last value it finds for the property in the properties file.
I have created a sample Java project to demonstrate the issue here: https://github.com/peter-thomas-mgd/spring-multi-doc
The example shows how an identical properties file behaves differently when specified as a test property source called test.properties vs. when bootstrapped as the default application.properties.
Comment From: philwebb
This is a little annoying, but unfortunately @TestPropertySource is part of the Spring Framework codebase and as such doesn't know anything about multi-document property files.
I'm not sure on the best way to fix this. We could document it as a limitation, or we could perhaps develop an alternative annotation. It's a tricky problem because there are other aspects (such as spring.config.import) that also won't work.
In the meantime, you might want to look at @SpringBootTest or SpringBootContextLoader which uses SpringApplication and so should load the full application.properties file.
Comment From: peter-thomas-mgd
Thanks for responding so quickly. We have already implemented a workaround, which is using @SpringBootTest exactly as you suggest, and moving our properties to application.properties. However, I wanted to make sure this issue got on the radar, since I'm sure other teams are going to run into this issue at some point.