Dynamic environment variables with @QuarkusIntegrationTest

[erke-soptim]

Hi there 👋

I am currently stuck trying to introduce @QuarkusIntegrationTest to an existing codebase. My test setup requires starting a LocalStack container exposing an api that I want to talk to in a test. This is done in a custom QuarkusTestResourceLifecycleManager. To allow my code to talk to the "real" api in production and the local api when testing, the corresponding service class has a static client field that gets overriden in the lifecycle manager.

Service.java

public class Service {
    // this is the default client
    public static Client client = new Client("prod-url", "prod-secret");

    public void doSth() {
        client.call();
    }
}

MyLifecycleManager.java

public class QuarkusTestBase implements QuarkusTestResourceLifecycleManager {
    private final LocalStack container;

    @Override
    public Map<String, String> start() {
        // inject a test client
        Service.client = new Client(container.getURL(), container.getSecret());
    }
}

This works well when running non-native tests, but fails for native tests, because the Service is already compiled and cannot be modified by MyLifecycleManager. I tried passing container.getURL() and container.getSecret() via environment variables, but that does not seem to work, because I have no control over the process running the build artifact. I did find 33806, but that only seems to talk about static environment variables. I specifically need to inject environment variables that are only known at runtime.

Thanks in advance!

[quarkus-bot[bot]]

/cc @geoand (testing)

[geoand]

I'm actually surprised about the different behavior in native vs JVM test. Is there any chance you can attach a simplified sample application that exhibits the problematic behavior in action?
I'd like to run it myself.

Thanks

[erke-soptim]

Sure, working on it...

[HerrDerb]

@soptim-erke Just for clarification: are you trying to modify an application bean within a QuarkusTestResourceLifecycleManager?

[erke-soptim]

Yes, the service in question is annotated with @RequestScoped.

[HerrDerb]

Yes this will not work. During an QuarkusIntTest, you cannot access the application scope as it runs in a completely different context or even container. In a QuarkusTestResourceLifecycleManager you should not try to access the application itself at all. What you can do with is is prepare test containers and object which you will inject into your test class for example. You might be able to solve your problem by providing specific test properties.

[erke-soptim]

That's what I was suspecting - thanks for the clarification. Would this work if certain properties of my test containers are only available after QuarkusTestResourceLifecycleManager.start has run?

[HerrDerb]

I believe you need to provide more information.
Are "prod-url", "prod-secret" provided as properties?
What is the external service your client is connecting to?
Is quarkus already providing a devservice for it?