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

QuarkusComponentTest: support simplified constructor injection #43339

Open
mkouba opened this issue Sep 17, 2024 · 2 comments
Open

QuarkusComponentTest: support simplified constructor injection #43339

mkouba opened this issue Sep 17, 2024 · 2 comments
Labels
area/arc Issue related to ARC (dependency injection) area/testing kind/enhancement New feature or request

Comments

@mkouba
Copy link
Contributor

mkouba commented Sep 17, 2024

Description

QuarkusComponentTest does not support bytecode transformations yet and thus simplified constructor injection does not work.

Implementation ideas

We'll need something like #35473 first to be able to implement this feature.

@mkouba mkouba added kind/enhancement New feature or request area/testing labels Sep 17, 2024
@quarkus-bot quarkus-bot bot added the area/arc Issue related to ARC (dependency injection) label Sep 17, 2024
Copy link

quarkus-bot bot commented Sep 17, 2024

/cc @Ladicek (arc), @manovotn (arc)

@holly-cummins
Copy link
Contributor

Popping this into the test classloading working group backlog. We can take it back out if we decide that's not a logical home for it. #34681 carefully avoids touching anything to do with @ComponentTest (and seems to be mostly getting away with it, in terms of not breaking those tests). However, thinking about it, I think the basic 'load tests with the classloader used to run them' approach should extend nicely to this scenario.

If someone was brave enough to start prototyping, in #34681 I think the natural hook point is in FacadeClassLoader. Adding something for component tests in there would allow the classloading to be intercepted, which would then allow pre-execution bytecode manipulation. But at the moment #34681 makes @Ladicek's changeset look like a model of pretty, clean code, so waiting a little while longer for #34681 to settle and become less ugly makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/arc Issue related to ARC (dependency injection) area/testing kind/enhancement New feature or request
Projects
Development

No branches or pull requests

2 participants