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

@WireMockTest usually requires @DirtiesContext #42

Open
otrosien opened this issue Nov 29, 2016 · 10 comments
Open

@WireMockTest usually requires @DirtiesContext #42

otrosien opened this issue Nov 29, 2016 · 10 comments

Comments

@otrosien
Copy link
Contributor

Due to the fact that the wiremock test execution listener adds a new property source that is unknown when we started the application context from a different test. So we need to restart the application context, in order to access our wiremock.port property. We need to find a better approach.

@otrosien otrosien added the bug label Nov 29, 2016
@otrosien
Copy link
Contributor Author

otrosien commented Jan 5, 2017

look at ContextCustomizer from spring framework 4.3

@poznachowski
Copy link

Hi,
You may find this helpful: https://github.com/neoteric-eu/neo-starters/tree/development/neo-starter-test/src/main/java/eu/neoteric/starter/test/wiremock
We did something similar but using MockBean.

The problem I'm struggling with right now, how to force FeignClients to use Wiremock without Ribbon, which translates to using FeignClient with url parameter (it will fallback to normal Feign). Wondering if you ever thought about it?

@otrosien
Copy link
Contributor Author

AFAIR we had this in place. If you use @FeignClient(url=".. some spel expression") you can make that spel expression resolve to the WireMock location.

@otrosien
Copy link
Contributor Author

@poznachowski thanks for the link BTW. Important part here is that we don't let wiremock choose a random port, but we probe a free port and save this in a spring property, which later gets assigned as fixed port to wiremock. This property is the sauce for further configuration of your FeignClient or other services.

@poznachowski
Copy link

np :) I think that I don't see the difference. In my solution I also look up for a free port, starts Wiremock with that, and sets that all Feign clients connects to it. Does that behaviour differs from yours?
I don't have to provide specific Feign clients to point to Wiremock server, as all of them base on the AbstractLoadBalancer class.

With using spel expression, that would require providing in every test with Wiremock Feign client name and I wanted to avoid that and come up with generic solution for all Feign clients available.

@otrosien
Copy link
Contributor Author

otrosien commented Feb 15, 2017

hm. You might be overengineering things. From my point of view the test should know which feign client it needs to wire to wiremock. Not all FeignClients on the classpath should - only the one you're interested in testing.

@UlfS @jensfischerhh correct me if I'm wrong, but what we're doing is something along the lines of this:

SomeFeignClient.class

@FeignClient(url="${someFeignClient.baseUri}")
interface SomeFeignClient {}

.. and application-test.yml

someFeignClient.baseUri: http://localhost:${wiremock.port}/

@otrosien
Copy link
Contributor Author

.. haven't touched spring code for a while, so i feel a bit rusty... ;-)

@ulfsauer0815
Copy link

@otrosien Yup, that's what we're doing, but I think we are using the @SpingBootTest annotation to set the property, otherwise wiremock.port wouldn't be available yet at the time the application-test.yml is processed.

@otrosien
Copy link
Contributor Author

@UlfS actually both should work. In client/src/test/resources/application-test.properties there's a working example. Maybe we should add a test case with @SpringBootTest annotation.

@zjedi
Copy link

zjedi commented Dec 6, 2019

all our wiremock tests ended up being ignored, because they somehow pollute spring context and plain DirtiesContext is not enough. The only thing that helps is applying DirtiesContext before every test class (even those that have nothing to do with wiremock). Just not worth the trouble.

@jmewes jmewes removed the bug label Mar 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants