-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
WireMock with JUnit 5 #684
Comments
You can programmatically start and stop I'll mark this as a feature request as JUnit 5 support should start to be a priority soon. |
Thank you for your comment, and marking. |
You can use |
Some of WireMock's own acceptance tests actually do this in their base class, so might be worth checking that out if you're not sure what I mean. |
Thanks for your kind comment. I'll check it. |
Please look at https://github.com/lanwen/wiremock-junit5 (will be available in maven central soon) |
@lanwen nice! Could you do this as class level fields instead of (or additionally) method parameters? |
@sta-szek Like a class rule? |
@lanwen exactly - just to simplify as much as possible. |
@lanwen thanks for the nice code! |
What the difference? |
It's an approach that uses annotated fields. See ExampleTest |
@lanwen can you help me how to wiremock-junit5 for custom port. void function(@WiremockResolver.Wiremock WireMockServer server) throws IOException { but in this, i can't set server port for which server need to start, Is there is any way to do that ? |
Any news about this? |
@ghilainm for me rewriting rule to Junit5 extension looks like this: https://github.com/jmayday/wiremock/commit/908cbb20d19cf7dcabcca3de28a2712fd895e472 (I'm not sure if it satisfies requirements for pull request though... @tomakehurst?) As server starts on random port, we need to build also a webclient with correct url. It might be achieved in beforeAll method in a test class:
|
I'm a bit reticent about making WireMock dependent on both JUnit 4 and 5. Dropping 4 isn't an option at the moment as it's still pretty widely used. Do you think there's much disadvantage in adding JUnit 5 support via a separate library? |
Yes, an official but optional library should be quite helpful. |
What about splitting Wiremock library in two -- The |
Having an 'official' Wiremock JUnit5 extension would be valuable. I actually expected to find a JUnit 5 extension when I have a JUnit 4 rule. And I think an optional dependency on JUnit 5 would be no problem at all, would it? |
@tomakehurst Sure, I realize that this is not so much different from what you have now. This is by design. The only difference is that JUnit 4 dependency is explicitly divorced from the core dependency. Should not be difficult to achieve. |
I'm coming around to the idea of making both JUnit 4 and 5 optional/provided dependencies. I'm going to look at this (with the usual caveats about being busy and it not happening quickly). |
Any update on this? |
Any update on this? |
@tomakehurst Is this something any of us could help with? I can imagine splitting out the junit4 dependencies can be a hairy task with some architectural impact, so I would understand if you want to do it yourself since Wiremock is your baby :-) |
@fransflippo @tomakehurst I would recommend using: @AutoConfigureWireMock from our friends from spring's 'org.springframework.cloud:spring-cloud-contract-wiremock' - it's working great with Junit5 and you can customize it it you want :) |
Great to see @Patouche step in to add a JUnit Jupiter extension 🚀 In the meantime and for those who are looking for a solution to start WireMock before all test methods (as far as I can see it, no community extension allows this as they are implementing the
With the initializer above you'll start WireMock as part of the bootstrapping phase of the Spring Context, register it as a Spring Bean and can override base URLs for your HTTP clients. Next, you need to activate/include this initializer with
You can find a detailed explanation as part of this blog post. |
So @Patouche any news? |
Hey folks, I've been working on this. I think it's pretty much ready to go, but I'd appreciate any feedback I can get before I release it. Please take a look at the docs on the branch if you're interested: #1439 (comment) I've also pushed a standalone build here if you'd like to try it: https://github.com/tomakehurst/wiremock/releases/tag/2.31.0-beta |
@tomakehurst I just gave it a try. Unfortunately, the beta version is not available on central and JitPack has issues building the project. So I downloaded the JAR and added it to my local repo:
Works like a charm, almost like a drop-in replacement – great work! Side note: it's JUnit 5, so you can remove the |
Thanks for the feedback @beatngu13! It's on my list to get JitPack working so should be easier with future betas. |
@tomakehurst one suggestion: maybe use |
I agree it's less surprising to default to 8080, but OTOH it prevents you from running your tests in parallel without switching everything over to the programmatic form, which you tend to want to do only when you've got 100s of tests and your build is starting to feel slow. Also, defaulting to the random port nudges developers to use the WireMock's base URL methods rather than I'm genuinely in two minds though, not least because I can see myself spending the next 5 years telling every other mailing list poster about the random port. |
There's another possibility, arguably a middle way. I've been thinking it'd be good to support automatic JVM proxy setup in a similar fashion to Hoverfly, whereby forward proxying is enabled and the JVM system properties for proxy config are set to point to it so that you can mock multiple domains in a single instance. I wouldn't want to turn this on by default, but it'd be nice to have it available declaratively so I was wondering about creating a subclass to the extension that turns this option on e.g. @ExtendWith(WireMockExtensionWithJvmProxy.class) Perhaps we could also have something like: @ExtendWith(WireMockExtensionRandomPort.class) or if random port is kept as the the default: @ExtendWith(WireMockExtensionPort8080.class) Thoughts? |
Ah, I see. Using a random port definitely makes sense when executing the tests concurrently. You also know your user base way better than I do and what default makes more sense. Regarding @Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@ExtendWith(WireMockExtension.class)
public @interface WireMockTest {
// null means random port
Integer httpPort;
// more core config properties
} Which can be used like: @WireMockTest
class DeclarativeWireMockTest { } If a static port is desired: @WireMockTest(httpPort = 8080)
class DeclarativeWireMockTest { } |
Yes, that's much nicer isn't it. I'll go with that. |
I've updated the branch to include this ☝️ now. I'm still trying to figure out a better way to publish a beta build than putting the standalone JAR on Releases. So far:
If anyone has any other ideas I'm all ears... |
Strange, it seems to be a client side problem. I have snapshots publishing in a few Gradle projects and it used to work fine. Do you have some CI logs to take a look (and configuration in a branch)? |
@szpak there's nothing useful in the logs really, just Do you have a Gradle build file with working sonatype snapshot publishing you could share so I can compare? |
OK, looks like the issue is that you have to actually have I've pushed a |
Yup, they have separate repos for snapshot and release versions and are strict about content. I'm glad you solved it! |
There seems to be some issue with the setup of Gradle for the JUnit BOM. If you look at the pom you can see the following <dependency>
<groupId>org.junit</groupId>
<artifactId>junit-bom</artifactId>
<version>5.7.1</version>
<scope>runtime</scope>
</dependency> i.e. it adds the BOM as the runtime dependency rather than in the Not sure if this is a Gradle bug or an issue with the configuration in the build It makes downstream Gradle builds unhappy (running Gradle 7.2)
This is because Gradle "knows" that the BOM is a "platform" but it's being added as a dependency. Excluding the dependency from Wiremock makes things happy testImplementation("com.github.tomakehurst:wiremock-jre8:2.31.0-SNAPSHOT") {
exclude(group = "org.junit", module = "junit-bom")
} |
Thanks for reporting this. Would you mind sharing your Gradle build file (or enough of it) so I can reproduce this? Also, does this happen with Java versions < 16? |
It's publicly available on the competing code hosting platform - https://gitlab.com/bmorris591/volvooncall-mysql I've pushed up a branch without the exclusion to show the error, mainline has the exclusion and compiles happily. |
Thanks for the detailed info @bmorris591! I think I've figured out the solution, so I'll push another snapshot tomorrow. |
@bmorris591 I could fix the Gradle synchronization with
Is it the same to you? |
New 2.31.0-SNAPSHOT pushed. This seems to fix the issue in your project @bmorris591. |
That got a green build when I reran the spike linked above. Mainline build has also completed successfully after merge. Thanks! |
Seems fixed and this works for me! At first I thought we still had to make our own extensions because this issue was still open. Posting the link above so others can find it too. |
Good point, closed! |
In JUnit 5,
@Rule
and@ClassRule
is superseded by@ExtendWith
, which requires extension class.And it seems like extension for WireMock is not yet supported.
Is there any alternative way to use WireMock with stubbing and verification via JUnit 5?
The text was updated successfully, but these errors were encountered: