-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
Describe the bug
Since Quarkus 3.16 (including 3.16.1, 3.15.1 is fine) our integration test classes start literally test-resources from all literally all @WithTestResource
annotations, even for those that are not (yet) executed.
Before 3.16(.1), only the test-resource for the currently running integration-test-class were started.
The major change in behavior that I could identify so far is in io.quarkus.test.common.TestResourceManager#restrictToAnnotatedClass
, which now delegates to the TestResourceClassEntryHandler
implementations (for @QuarkusTestResource
and @WithTestResource
). (Admittedly, restrictToAnnotatedClass
could never yield true
before 3.16.)
Since restrictToAnnotatedClass() checks for == RESTRICTED_TO_CLASS
on all annotations "everywhere", it initialized and starts all test resources. This can lead to e.g. 4 Keycloaks, 2 Minios and a bunch of other containers 🤷
Our integration-tests are annotated using @WithTestResource(value = xyz.class)
, leaving the default scope MATCHING_RESOURCES
to leverage the ... Quarkus will not restart when running consecutive tests that use the same set of resources.
behavior.
The current workaround is to set the scope to RESTRICTED_TO_CLASS
.
/cc @geoand
Expected behavior
- Only have the test-resources for the current test class running
- Group tests by test-resources, considering "initArgs"
- Don't start the "whole world" ;)
Actual behavior
No response
How to Reproduce?
I do have a reproducer, but it's still a (local) WIP to bump Quarkus to 3.16.1 in Nessie, including the workaround mentioned above.
Output of uname -a
or ver
No response
Output of java -version
No response
Quarkus version or git rev
No response
Build tool (ie. output of mvnw --version
or gradlew --version
)
No response
Additional information
No response