QuarkusTest TestProfile pollutes environment of QuarkusComponentTest

[ryandens]

Describe the bug

As described in #46035

Having a QuarkusTest provide config overrides via the TestProfile annotation pollutes the environment of other tests in the suite.
I was able to debug the QuarkusComponentTestExtension and inspect the resolved Config object. Using the org.eclipse.microprofile.config.Config.getConfigValue API, I was able to see that the incorrect config value was coming from system properties (I assume set by the quarkus test extension).

Expected behavior

As described in #46035

I understand the limitation with Quarkus tests and how the Test Profiles work by requiring a test ordering and a restarting of the Quarkus server (which is part of my motivation for wanting to move more of my tests to be QuarkusComponentTests rather than QuarkusTest).

However, it appears the orderer is unaware of QuarkusComponentTests. It would seem the server needs to either restart after the last QuarkusTest with a TestProfile, or QuarkusComponentTests needed to be ordered before QuarkusTests. I encountered this issue when my test order changed on a quarkus upgrade. However, this doesn't appear to be associated with any change to the QuarkusTestProfileAwareClassOrderer.

Previously, there was a workaround available using QuarkusTestProfileAwareClassOrderer. However, due to #48289 this is not available

I'm really excited by component tests and would like to use them more extensively. However, this bug means I cannot use them in a test suite with other Quarkus tests, which hinders migration efforts

Actual behavior

QuarkusTests with profiles do not close their resources properly still. In addition, the fix that closed the original bug was reverted in #46684.

It seems that the test isolation work did not fix this bug, but rather made it worse by also breaking the way for projects to work around it.

But, based on the description of the PR that reverted this #46684, the issues the new default ordering caused should be mitigated by recent work. I believe the right approach is to re-apply the ordering change and run component tests before quarkus tests.

How to Reproduce?

Reproducer: https://github.com/ryandens/quarkus-component-test-reproducer (updated for Quarkus 3.24.3)

1. Clone the project
2. Run the build, showing failing tests

Output of uname -a or ver

No response

Output of java -version

openjdk version "24" 2025-03-18 OpenJDK Runtime Environment Temurin-24+36 (build 24+36) OpenJDK 64-Bit Server VM Temurin-24+36 (build 24+36, mixed mode, sharing)

Quarkus version or git rev

3.24.3

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

------------------------------------------------------------ Gradle 8.14.3 ------------------------------------------------------------ Build time: 2025-07-04 13:15:44 UTC Revision: e5ee1df3d88b8ca3a8074787a94f373e3090e1db Kotlin: 2.0.21 Groovy: 3.0.24 Ant: Apache Ant(TM) version 1.10.15 compiled on August 25 2024 Launcher JVM: 24 (Eclipse Adoptium 24+36) Daemon JVM: /Users/ryandens/.sdkman/candidates/java/24-tem (no JDK specified, using current Java home) OS: Mac OS X 15.5 aarch64

Additional information

No response

[quarkus-bot]

/cc @geoand (kotlin)

[ryandens]

I believe this issue got incorrectly labeled with area/kotlin it likely should be area/testing

[geoand]

cc @mkouba @holly-cummins

[geoand]

Ι believe the right approach is to re-apply the ordering change and run component tests before quarkus tests.

Have you tried making this change? It probably makes sense to create a draft PR if you already have the relevant change ready

[holly-cummins]

Ι believe the right approach is to re-apply the ordering change and run component tests before quarkus tests.

Have you tried making this change? It probably makes sense to create a draft PR if you already have the relevant change ready

I think the problem that it broke everything else. :)

Well, not everything, but something. It shouldn't break everything, but it did. Guillaume did the change a while ago and then it caused drama, so Guillaume reverted his fix. I need to investigate why the simple-seeming fix broke things.

[ryandens]

Have you tried making this change? It probably makes sense to create a draft PR if you already have the relevant change ready

Yeah the issue reporting this change (#46459) did not attach a reproducer as far as I can tell so i don't have a great way to verify this change against their issue

I thought that the best approach was to raise an issue so we can agree on an approach before opening a PR with a change that was already reverted

[ryandens]

I performed a quick test to confirm, as I came across #48423. Tested with a locally built snapshot of Quarkus on the head of main, and it does not change the behavior described in this issue.

[mkouba]

So if I understand it correctly the main problem is that QuarkusTestProfile config turns into system properties that are set when the profile is used and restored/cleared when the test app stops. In theory, we might just skip the system properties/ENV variables config sources for QuarkusComponentTests and keep the properties files sources (e.g. application.properties) and test config properties. Or am I missing something?

[holly-cummins]

So if I understand it correctly the main problem is that QuarkusTestProfile config turns into system properties that are set when the profile is used and restored/cleared when the test app stops. In theory, we might just skip the system properties/ENV variables config sources for QuarkusComponentTests and keep the properties files sources (e.g. application.properties) and test config properties. Or am I missing something?

Oh yes, I like that; if we could switch away from system properties and use a config source, it might have a number of benefits.

[mkouba]

So if I understand it correctly the main problem is that QuarkusTestProfile config turns into system properties that are set when the profile is used and restored/cleared when the test app stops. In theory, we might just skip the system properties/ENV variables config sources for QuarkusComponentTests and keep the properties files sources (e.g. application.properties) and test config properties. Or am I missing something?

Oh yes, I like that; if we could switch away from system properties and use a config source, it might have a number of benefits.

I guess that you're talking about this code in AppMakerHelper. which makes sense but I was talking about this code, so basically replace the addDefaultSources() with addPropertiesSources() which IMO also makes sense for "component" tests.

In theory, we could also make it configurable (and use addPropertiesSources() by default).

[holly-cummins]

I guess that you're talking about this code in AppMakerHelper. which makes sense but I was talking about this code, so basically replace the addDefaultSources() with addPropertiesSources() which IMO also makes sense for "component" tests.

Oh no, I hadn't got as far as actually properly thinking, so I wasn't thinking about any specific code. :) But you're right that the code you link to isn't going to be helping anything, and should go.

Actually, that's not quite true that I didn't have anything in mind. From your comment, I was half-thinking of [this overrideConfigmethod](https://github.com/quarkusio/quarkus/blob/092de9565f3193cbb2daf2f8a9a1be5f658533e5/core/deployment/src/main/java/io/quarkus/runner/bootstrap/StartupActionImpl.java#L291-L293) inStartupActionImpl`. It's the mechanism for setting properties from test profiles, and is causing me problems on another thing. It does use a proper config source so I think it's 'innocent' in this discussion, but it can fight with system properties, which is why I was looking at it.