-
Notifications
You must be signed in to change notification settings - Fork 6
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
Quarkus 3 - consumer tests cannot directly access pact MockServer
in test methods in dev mode
#73
Comments
Quarkus 3 brings two major changes - the javax/jakarta namespace change, and a change to classloading. Quarkus 2 coredefined many pact modules to be parentfirst. In Quarkus 3, that will be done by this extension. The Quarkus 3 kotlin extension also stopped loading kotlin parent first. I was able to remove all the parent-first dependencies for the consumer. For the provider, oddly, I had it working with a single parent-first dependency in December, but now I needed the full set. I will continue working to see if I can reduce it down to a minimal set, or having both extensions in the same project will be a problem. I did have to disable one test, and have raised quarkiverse#73, but I think it's not a serious issue.
Hi! I'm facing this problem also. Probably because I'm following an outdated tutorial... would anybody be so gentle to tell me how can I do something like this:
Without facing the error mentioned in this issue? Thank you so much in advance! |
Using @MockServerConfig annotation perhaps? |
Ah, there goes my hope that hardly anyone would hit this. :) It's a bit inelegant, but you can hand-craft the equivalent of For example, if you have
then you know your base URL will be something like It's not mentioned in the Pact docs that I can see, but my IDE is showing On the other hand, one advantage of hardcoding the port is it means you could do something like this instead of using the rest client builder
You would also need something like this in your
and this on the actual
A final note is to be careful of spending too much energy testing your |
Wow! Thank you so much for your suggestion, @holly-cummins !! I'll give a try in a shortwhile!! BTW, I've changed my original message a little bit, just to remove the "Norsu" name (it's some kind of a keyword in my company). Thank you very much again and sorry for the inconvenience :( |
Hi @holly-cummins, we also ran into this issue during our Quarkus 3 migration. I disagree regarding your assessment on the priority - I think injecting the MockServer can be a valid requirement sometimes. For example, in our project we are using a custom Wiremock server that is started as part of Dev Services and acts as a proxy to the Pact Mock Server. This accomplishes two things for us:
That aside, the workaround of setting a hard-coded port and avoiding to inject the MockServer does work, but it's still problematic, especially when using Pact in multiple services that run on the same CI. Is there anything we can do here to get this fixed? I saw that there were similar issues with Quarkus Testing in the past that have been worked around (see for example quarkusio/quarkus#24872), maybe something similar could be done here? Or do we have to wait for JUnit 5.10 to drop so we can fix the classloader stuff (as mentioned in quarkusio/quarkus#22611)? |
Thanks for the great analysis, @markusdlugi. I love that idea about the Wiremock proxy. I agree, adding an extra proxy does sound like a good way forward for #60. Do you have any sample code you can share? I can't totally picture what you mean about the I also agree that I guessed wrong about the priority! My assumption has been that it needs JUnit 5.10 for a fix, and I'm planning to prepare a PR for that, so that it's ready to drop as soon as 5.10 GAs. However, it's been a while since I've looked at the issue, so I'll try again. I did try extending the approach from quarkusio/quarkus#22611 but I stopped after adding support about ten more classes, because it seemed like I was never going to get to the end of the list. |
On the bright side, whether we fix it or not, we get to call the issue "The Clone Wars." |
I'm no expert here and probably don't know what I'm talking about, but if obtaining the URL from the |
I think that's definitely where we want to go, @Ladicek. At the moment, any Quarkus-driven injection doesn't work because of classloader problems (the tests run from the un-instrumented test class, not the one updated with Quarkus magic). Once that's sorted out (which I hope will be possible once we move to JUnit 5.10), all sort of developer experience improvements should be possible. |
Getting closer ... with my prototype on quarkusio/quarkus#34681 the |
Sounds good, thanks a lot for all the experimentation :) |
It looks like this may be fixed by quarkusio/quarkus#40601 (although some other scenarios are broken by that same change!). That change will hopefully be available in Quarkus 3.11, if a needed JUnit upgrade releases in time. |
I believe this is fixed in Quarkus 3.12, but leaving this open to track making a new branch with that level of Quarkus as the minimum version and enabling tests. |
With the switch to Quarkus 3, we've moved to running more of the Pact infrastructure in the Quarkus classloader, rather than the system one. One side effect of this is that direct access to the pact
MockServer
gives classloading conversion errors (on Java 17 and higher):Here is an example of a problematic access:
In general, test code should have no reason to access the
mockServer
directly, because the consumer tests should be testing the consumer, not the mock. The access here was to actually try and test the pact extension.Because of that, I believe this is a low priority issue.
The text was updated successfully, but these errors were encountered: