application.properties can contain general settings. Examples: - spring.datasource.url=... - server.port=...
It can also contain settings about testing: - spring.test.database.replace=...
The setting spring.test.constructor.autowire.mode can not be set in application.properties. It must be set in test/resources/spring.properties
This is annoying: - some settings are in application.properties, other settings are in spring.properties - I regulary have a spring.properties with only one setting: spring.test.constructor.autowire.mode
Can spring.test.constructor.autowire.mode be set in application.properties ?
Comment From: wilkinsona
Thanks for the suggestion. Unfortunately, I'm not sure that this could be implemented in a way that wouldn't be confusing. Not, at least, without some changes to Spring Framework.
As you know, the property is typically set in spring.properties. This is a Spring Framework feature and it uses a single such file located from the classpath. Alternatively, they can be set via static method calls. The properties are then read using static methods. In other words, the properties aren't scoped to a particular test class or application context, but to the class loader.
If the properties could be set in application.properties, this would theoretically allow different tests to have different values for those properties. For example, the properties could be configured in a file that's specific to a profile that's activated by a subset of the project's tests. There's no way for us to set the properties for a specific test class or application context so we'd run into problems with scoping and parallel test execution.
We'd need some changes to Spring Framework to allow the Environment to be used as a source for SpringProperties. This would be a fairly fundamental change as it would require moving away from the use of static methods to something that can work with the Environment. There may be cases where a property that can be set via SpringProperties controls what appears in the environment so there's a chicken and egg problem too.
All in all, I don't think we should try to support setting SpringProperties values via application.properties and the Environment. Let's see what the rest of the team thinks.
Comment From: sbrannen
@hansdesmet, you may not be aware of it, but as of Spring Framework 5.3 the spring.test.constructor.autowire.mode property can be set via the JUnit Platform configuration parameter support (e.g., in junit-platform.properties in the root of the classpath). See the Javadoc for @TestConstructor for details.
Thus, if you already have a junit-platform.properties file in your project, it's straightforward to add an entry for spring.test.constructor.autowire.mode to that file.
Comment From: hansdesmet
A nice alternative would be that @ExtendWith(SpringExtension.class) works like @Component, @Controller, @Service, ... :
When you put @Component, @Controller, @Service, ... on a class,
Spring applies dependency injection on the parametrized constructor of that class.
You don't need to type @Autowired.
If @ExtendWith(SpringExtension.class)would do the same an a test class,
it would be an easy way to do dependency inection in tests (in a consistent way as you do controllers, services, ...)
Comment From: sbrannen
@hansdesmet, autowiring semantics in tests is a topic specific to Spring Framework and has been discussed in various Framework issues including https://github.com/spring-projects/spring-framework/issues/18629, https://github.com/spring-projects/spring-framework/issues/22286, and https://github.com/spring-projects/spring-framework/issues/22924.
Comment From: philwebb
Given the discussions above I think using junit-platform.properties is a better option than adding the support to application.properties. In my opinion it's best if we keep direct test concerns out of the application.properties file.
Thanks anyway for the suggestion.