Skip to content
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

Allow ArgumentsProviders to register additional extensions #3282

Open
1 task
fmeum opened this issue May 5, 2023 · 7 comments
Open
1 task

Allow ArgumentsProviders to register additional extensions #3282

fmeum opened this issue May 5, 2023 · 7 comments

Comments

@fmeum
Copy link

fmeum commented May 5, 2023

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() to ArgumentsProvider. In ParameterizedTestExtension, forward the additional extensions to the ParameterizedTestInvocationContext.
@marcphilipp
Copy link
Member

@fmeum I did a quick spike of making the ArgumentsProvider accessible via ExtensionContext. Would that work for your use case?

@fmeum
Copy link
Author

fmeum commented May 6, 2023

@marcphilipp That's a neat solution for my use case with little new API surface. I like it, thanks for the quick response!

@fmeum
Copy link
Author

fmeum commented May 8, 2023

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.

@fmeum
Copy link
Author

fmeum commented May 10, 2023

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

@marcphilipp
Copy link
Member

@fmeum Thanks for asking! I'd like to discuss this with the team first to avoid making you go through that unnecessarily.

@marcphilipp
Copy link
Member

Team decision: Wait for additional interest from the community since we don't perceive this as a common use case.

@rendenyoder
Copy link

rendenyoder commented May 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants