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

QuarkusTest reloading CDI for each test class with v3.13 (related to @WithTestResource) #42365

Closed
PedroRodP opened this issue Aug 7, 2024 · 8 comments
Labels
area/arc Issue related to ARC (dependency injection) area/testing kind/question Further information is requested

Comments

@PedroRodP
Copy link

Describe the bug

New annotation @WithTestResource from v3.13.0 restricts the resource to the annotated class by default, so I would expect it to be executed once per test class. But I noticed that using it in this way also makes the CDI to be reloaded, as my @Startup method is being called more than once when running the whole test set, so the execution time increase becomes remarkable if tasks are heavy.
When setting restrictToAnnotatedClass to false, it seems to fall back to the previous behavior, sharing both the resource and the context across the test classes (as with @QuarkusTestResource in v3.12.3).

Is this expected? I currently need to use dependency injection to configure an instance and execute some code just once when running all tests. I'm not using test resources for that since I can't inject a bean into these.

Expected behavior

I'd expect the QuarkusTestResourceLifecycleManager implementations to be isolated for each test class with the new @WithTestResource annotation default behavior, while my @ApplicationScoped class being created just once.

Actual behavior

Both QuarkusTestResourceLifecycleManager implementations and @ApplicationScoped classes are being created for each test class when using @WithTestResource(restrictedToAnnotatedClass = true).

How to Reproduce?

I uploaded this little project so you can check it. You can test the behavior by playing with the restrictToAnnotatedClass flag and checking the logs my test resource and my application scoped class are printing.

Output of uname -a or ver

Darwin Pedros-MacBook-Pro.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:59 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6030 arm64

Output of java -version

openjdk version "21.0.2" 2024-01-16

Quarkus version or git rev

3.13.0

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 8.8

Additional information

Time taken when restrictToAnnotatedClass = true

image image

You can see that my logs are printed twice (once per test class) and Quarkus was reloaded.

Time taken when restrictToAnnotatedClass = false

image image

Here there's no new logs, no reloading. And time has clearly decreased.

@PedroRodP PedroRodP added the kind/bug Something isn't working label Aug 7, 2024
@quarkus-bot quarkus-bot bot added the area/arc Issue related to ARC (dependency injection) label Aug 7, 2024
Copy link

quarkus-bot bot commented Aug 7, 2024

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

@mkouba
Copy link
Contributor

mkouba commented Aug 7, 2024

CC @edeandrea

@edeandrea
Copy link
Contributor

If you use @QuarkusTestResource(restrictedToAnnotatedClass = true) do you see the same behavior?

See #42298

@edeandrea
Copy link
Contributor

edeandrea commented Aug 7, 2024

And also, could you try downgrading your application to 3.12.3 and update to use @QuarkusTestResource(restrictAnnotatedClass=true) and see if behavior is consistent?

@edeandrea
Copy link
Contributor

I cloned the project and re-ran with Quarkus 3.12.3 using the @QuarkusTestResource annotations. I see the exact same results, which means this issue pre-existed the new @WithTestResource annotation. All that was done with that annotation was just a new "front door" to default to @QuarkusTestResource(restrictToAnnotatedClass=true).

With @QuarkusTestResource(value = MyTestResource.class, restrictToAnnotatedClass = true)

image

image

With @QuarkusTestResource(value = MyTestResource.class, restrictToAnnotatedClass = false)

image

image

@PedroRodP
Copy link
Author

PedroRodP commented Aug 7, 2024

@edeandrea yep, same behavior when using @QuarkusTestResource(restrictedToAnnotatedClass = true) with v3.13.0. Quarkus is reloaded for each test class
image

And also for v3.12.3, which is consistent.
image

So, as you mentioned in #42298, we can confirm it's only a change in the default behavior, not a new bug. But is this the intended way of it to work when using restrictToAnnotatedClass to true or should it be reviewed?

@edeandrea
Copy link
Contributor

So, as you mentioned in #42298, we can confirm it's only a change in the default behavior, not a new bug. But is this the intended way of it to work when using restrictToAnnotatedClass to true or should it be reviewed?

My guess is that it should be reviewed, but I don't think I'm the right person to review it. I don't know much about how it works behind the scenes. All I did was create a new annotation.

For the time being, you can use @WithTestResource(restrictToAnnotatedClass=false) to revert to previous default behavior.

cc: @maxandersen @gsmet

@geoand
Copy link
Contributor

geoand commented Aug 8, 2024

Is this expected? I currently need to use dependency injection to configure an instance and execute some code just once when running all tests. I'm not using test resources for that since I can't inject a bean into these.

This is not a bug, but it is the expected behavior.

What happens essentially is that Quarkus reruns the build time steps and "restarts" the application (in the same way that dev-mode "restarts" it).

@geoand geoand closed this as not planned Won't fix, can't repro, duplicate, stale Aug 8, 2024
@geoand geoand added kind/question Further information is requested and removed kind/bug Something isn't working labels Aug 8, 2024
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/question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants