Allow `ArgumentsProvider`s to register additional extensions
I have a use case in which I would like to intercept only certain invocations of a @ParameterizedTest, namely those where the arguments come from a particular ArgumentsProvider. Since the information about which ArgumentsProvider provided the current set of arguments isn't available in e.g. InvocationInterceptor#interceptTestTemplateMethod, this doesn't seem to be possible today.
TestTemplateInvocationContext#getAdditionalExtensions would allow doing that, but it can't be populated from an ArgumentsProvider. I thus propose exposing this functionality via a new getAdditionalExtensions() method on ArgumentsProvider.
Deliverables
- [ ] Add a new default method
List<Extension> getAdditionalExtensions()toArgumentsProvider. InParameterizedTestExtension, forward the additional extensions to theParameterizedTestInvocationContext.
@fmeum I did a quick spike of making the ArgumentsProvider accessible via ExtensionContext. Would that work for your use case?
@marcphilipp That's a neat solution for my use case with little new API surface. I like it, thanks for the quick response!
I noticed one limitation that makes this solution slightly less useful than I first thought: A single annotation cannot be meta-annotated with multiple @ArgumentsSources since @ArgumentsSources does not list ANNOTATION_TYPE in @Target. Is this intentional?
As a result, we can't just have our custom @ParameterizedTest annotation register multiple ArgumentsProviders that we can then distinguish using the instance reference in the store. The proposed change would still help us distinguish our own arguments from those provided by user-registered @ArgumentsSources though.
Edit: I confirmed that this can be worked around by making the second @ArgumentsSource an annotation on a new helper annotation that can then be applied to the same annotation as @ArgumentsSource.
@marcphilipp Since I don't know the usual processes for contributions yet: Would it help if I turned your spike into a PR with tests and docs or is this something you would like to do yourself?
@fmeum Thanks for asking! I'd like to discuss this with the team first to avoid making you go through that unnecessarily.
Team decision: Wait for additional interest from the community since we don't perceive this as a common use case.
For what it's worth, I would also find this to be a useful addition and have been wanting to do something similar to what fmeum is suggesting.