-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Mixed up Test configuration when using @ResourceArg #22025
Comments
Thanks for reporting. I tried to run the reproducer but got:
|
Try deleting that jar ( |
Didn't work unfortunately, the issue persists |
That's super odd.. I know it's coming from |
Is there any chance you can reproduce the same problem in a simpler (preferably Maven) project? |
Just to try to get a sense of what is going on, which |
There should be only one implementation to run: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/blob/main/software/open-qm-base-station/src/test/java/com/ebp/openQuarterMaster/baseStation/testResources/TestResourceLifecycleManager.java and I created a simpler reproducer: It has two simple tests verifying the config is set correctly, and showing that config is overridden when it shouldn't be |
Great, thanks! I'll try it out soon |
Is that reproducer part of a different project? Because if it isn't, I'm likely to face the same Gradle issue |
Same git repo, different quarkus project, much fewer dependencies (no yaml!) |
Cool, thanks |
I want to get some clarity on what your expectations are on when these |
I expect that the tests within a test class are run against a quarkus service configured in the way described via the class annotations. I feel like it might be a common use case to provide options to the lifecycle manager that would have an effect on running configuration (that differs between tests/classes) and therefore need to be test-class-specific. As in my op, I wish I didn't have to use the args but AFAIK there is no way to determine anything about the run from the lifecycle manager (know current profile, access to existing configs, etc). If I could know there if Keycloak is needed or not, I could avoid needing the arg to tell me. |
Additionally, I am personally okay with the caveat of "the server will need restarted between tests of different configs" as we already do this with test profiles. Perhaps there could be a |
This applies for implementations that don't specify the order Relates to: quarkusio#22025
I think there is a misconception about when So in your case, it seems like two |
Okay, that does make sense, I was unaware of the That being said, I feel it's a little bit of an imperfect solution as I need to apply this argument to all tests of the separate profile. I might still ask for a config value to apply this globally or make the logic smarter to know when to use what lifecycle manager based on profile/ lifecycle manager/ manager args |
I would suggest opening a new issue asking for exactly that and can consider it. |
This applies for implementations that don't specify the order Relates to: quarkusio#22025
This applies for implementations that don't specify the order Relates to: quarkusio#22025 (cherry picked from commit 232f3de)
Describe the bug
TL:DR; When running tests with different
@ResourceArg
s to configure a TestLifecycleManager, the configuration of different tests get thrown around and override others, breaking tests meant to run with specific configurations. Originally on SO: https://stackoverflow.com/questions/70268026/quarkus-mixed-up-test-configuration-when-using-resourceargSo, I have a service that has tests that run in different configuration setups. The main difference at the moment is the service can either manage its own authentication or get it from an external source (Keycloak).
I firstly control this using test profiles, which seem to work fine. Unfortunately, in order to support both cases, the
ResourceLifecycleManager
I have setup supports setting up a Keycloak instance and returns config values that break the config for self authentication (This is due primarily to the fact that I have not found out how to get the lifecycle manager to determine on its own what profile or config is currently running. If I could do this, I think I would be much better off than using@ResourceArg
, so would love to know if I missed something here. Maybe a potential improvement for the future).To remedy this shortcoming, I have attempted to use
@ResourceArg
s to convey to the lifecycle manager when to setup for external auth. However, I have noticed some really odd execution timings and the config that ends up at my test/service isn't what I intend based on the test class's annotations, where it is obvious the lifecycle manager has setup for external auth.To be specific, the config value that breaks things for self-auth tests is
mp.jwt.verify.publickey.location
, as the code grabs the public key from Keycloak to verify jwt's (which breaks the verification of self-signed keys!)Additionally, it should be noted that I have my tests ordered such that the profiles and configs shouldn't be running out of order; all the tests that don't care are run first, then the 'normal' tests with self auth, then the tests with the external auth profile. I can see this working appropriately when I run in intellij, and the fact I can tell the time is being taken to start up the new service instance between the test profiles.
Looking at the logs when I throw a breakpoint in places, some odd things are obvious:
start()
method of myTestResourceLifecycleManager
has been called twicestart()
method has now been called 4 times; appears that things were started in the same order as before again for the new run of the appThere could be some weirdness in how Intellij/Gradle shows logs, but I am interpreting this as:
At this point I can't tell if I'm doing something wrong, or if there's a bug.
Test class example for self-auth test (same annotations for all tests in this (
test
) profile):Test class example for external auth test (same annotations for all tests in this (
externalAuth
) profile):ExternalAuthTestProfile
extends this, providing the appropriate profile name:Lifecycle manager:
Expected behavior
In any particular test class, I expect the configuration of the running quarkus app to match what the annotations set.
Actual behavior
The configuration of the running tests isn't what the test class annotation set.
How to Reproduce?
The app can be found here: https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/main/software/open-qm-base-station
The tests are currently failing in the ways I am describing, so feel free to look around.
Note that to run this, you will need to run
./gradlew build publishToMavenLocal
in https://github.com/Epic-Breakfast-Productions/OpenQuarterMaster/tree/main/software/libs/open-qm-core to install a dependency locally.Output of
uname -a
orver
Linux GeneralDevBox 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.20.04) OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.20.04, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.5.0.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)Gradle 7.3
Additional information
No response
The text was updated successfully, but these errors were encountered: