Skip to content

Allow to set spring.test.constructor.autowire.mode in application.properties #25083

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hansdesmet opened this issue Feb 2, 2021 · 5 comments
Closed
Assignees
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@hansdesmet
Copy link

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 ?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 2, 2021
@wilkinsona
Copy link
Member

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.

@wilkinsona wilkinsona added the for: team-attention An issue we'd like other members of the team to review label Feb 2, 2021
@sbrannen
Copy link
Member

sbrannen commented Feb 2, 2021

@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.

@hansdesmet
Copy link
Author

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, ...)

@sbrannen
Copy link
Member

sbrannen commented Feb 8, 2021

@hansdesmet, autowiring semantics in tests is a topic specific to Spring Framework and has been discussed in various Framework issues including spring-projects/spring-framework#18629, spring-projects/spring-framework#22286, and spring-projects/spring-framework#22924.

@philwebb philwebb self-assigned this Feb 22, 2021
@philwebb
Copy link
Member

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.

@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged labels Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

5 participants