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

QuarkusTestResourceLifecycleManager: Unable to reuse testcontainers instances #43395

Closed
nicolasduminil opened this issue Sep 19, 2024 · 3 comments
Labels
area/testing kind/question Further information is requested

Comments

@nicolasduminil
Copy link

Describe the bug

In a Quarkus 3.11 project, I have an integration test that runs a REST API as a Docker image, via testcontainers. In order to avoid starting testcontainers for each test, the withReuse(true) option is used.

Expected behavior

I expect that testcontainers starts once, for the first test, and stays active such that all the remaining tests use this same instance.

Actual behavior

testcontainers is started and stopped before and after each test.

How to Reproduce?

$ git clone https://github.com/nicolasduminil/quarkus-test-resource-lifecycle-manager-issue.git
$ cd quarkus-test-resource-lifecycle-manager-issue
$ mvn install

testcontainers will start before the execution of CurrentTimeIT, it will be stopped after and will be restarted again before the execution of CurrentTimeResourceIT.

Output of uname -a or ver

Linux nicolas-XPS-15-9570 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

java version "21.0.3" 2024-04-16 LTS Java(TM) SE Runtime Environment (build 21.0.3+7-LTS-152) Java HotSpot(TM) 64-Bit Server VM (build 21.0.3+7-LTS-152, mixed mode, sharing)

Quarkus version or git rev

3.11.0

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

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: /opt/apache-maven-3.9.5 Java version: 21.0.3, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-21-oracle-x64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"

Additional information

Outside the Quarkus environment and without using QuarkusTestResourceLifecycleManager, testcontainers behave as expected when reused.

@nicolasduminil nicolasduminil added the kind/bug Something isn't working label Sep 19, 2024
@nicolasduminil
Copy link
Author

nicolasduminil commented Sep 19, 2024

I just realized that commenting out the restrictToAnnotatedClass = true property in the integration tests fixes the issue. But this isn't satisfactory as, in this case, all the tests, including the unit ones, which aren't annotated with @QuarkusTestResource and don't need testconatiners, will try to launch it and will fail, for different reasons.
So, I need to be able either to annotate the integration tests with restrictToAnnotatedClass = true and to launch testcontainers only once for all of them, or to not annotate the integration tests with restrictToAnnotatedClass = true and to avoid trying to start testcontainers for the the unit tests.
It's a bit unclear what I'm explaining here, not sure that I'm making myself understood ...

@geoand geoand added area/testing kind/question Further information is requested and removed triage/needs-triage kind/bug Something isn't working labels Sep 20, 2024
@geoand
Copy link
Contributor

geoand commented Sep 20, 2024

What you are seeing is actually the expected behavior and although I agree it is not ideal, the situation will be improved in Quarkus 3.16 with the updated version of @WithTestResource

@geoand geoand closed this as completed Sep 20, 2024
@nicolasduminil
Copy link
Author

Okay, thanks. Also, using @TestInstance(TestInstance.Lifecycle.PER_CLASS) in conjunction with @QuarkusTestResource behaves completely unexpected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/testing kind/question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants