Change @TestConstructor.autowire attribute into an enum

[philwebb]

I think it's possible that we might want to support different autowire modes with @TestConstructor in the future. Specifically, I think it would be nice if we could mix autowire with other extension mechanisms and have autowiring apply only when no other ParameterResolvers match.

I wonder if we should change autowire from a boolean to an enum so we can add more options in the future.

e.g.:

@TestConstructor(autowire=Autowire.ANNOTATED)
@TestConstructor(autowire=Autowire.ALL)
@TestConstructor(autowire=Autowire.REMAINING)

[philwebb]

Whoops, I raised this in the wrong repo. Transferred to spring-framework.

[sbrannen]

Thanks for raising the issue, @philwebb.

I agree that having an enum would allow for greater flexibility in the future. So, with that in mind, I'll likely make the change before 5.2 is released.

Regarding the proposed enum constants, allow me to make that a little bit more concrete.

• Autowire.ANNOTATED: only autowires if the individual parameter is annotated with @Autowired, @Qualifier, or @Value
• Autowire.ALL: autowires all parameters as if the constructor were annotated with @Autowired
• Autowire.REMAINING: ???

Is that what you had in mind, and what are the intended semantics for REMAINING?

I'm guessing you mean all remaining parameters that have not been claimed to be supported by other registered parameter resolvers.

have autowiring apply only when no other ParameterResolvers match.

Regarding that point, I agree that that would be nice. Unfortunately, there is currently no way to achieve that with the available extension APIs in JUnit Jupiter. Though, perhaps a future release of JUnit Jupiter will provide such support, in which case an enum would allow us to support that autowire mode as well.

Speaking of that, would you like to open an issue in the JUnit 5 GitHub repository requesting functionality along those lines? (if not, I can do that for you)

[philwebb]

I'm guessing you mean all remaining parameters that have not been claimed to be supported by other registered parameter resolvers.

Exactly. I just wanted to add it so we could consider the name in the context of the others.

Speaking of that, would you like to open an issue in the JUnit 5 GitHub repository requesting functionality along those lines?

I've raised junit-team/junit5#1945

[sbrannen]

@philwebb, what do you think of the changes in fc38bb4?

[philwebb]

@sbrannen LGTM 👍