WireMock

In the previous post, everything ran embedded, inside a single test class’s lifecycle. That is the right default for unit and component level tests. It stops working once several services in a pipeline all need to talk to the same stubbed dependency, or once integration tests running outside the JVM, a Postman collection for example, need to hit the same mock. That is what WireMock’s standalone mode is for. Running WireMock Standalone The same WireMock artifact that ran embedded can run as its own process, listening on a real port like any other service. ...

In the previous post, we stubbed a happy path response from an inventory service and verified our client built the right request. Happy paths are the easy part. What actually determines whether a service survives production is how it behaves when a downstream dependency does not cooperate, and that is much harder to test against a real dependency, since you cannot exactly ask another team’s service to time out on demand. WireMock’s fault simulation is built for exactly this. ...

In the previous post, we looked at why WireMock’s embedded mode is a strong fit for a Java test suite specifically. This post gets into the actual setup, adding WireMock to a Spring Boot project and writing a real stub against a downstream service. Adding the Dependency <dependency> <groupId>org.wiremock</groupId> <artifactId>wiremock-standalone</artifactId> <version>3.9.1</version> <scope>test</scope> </dependency> The standalone artifact bundles everything needed to run WireMock either embedded in a test or as its own process later, which keeps things simple while we are just getting started. ...

I have written a fair amount here already about Mountebank for service virtualization, and it has served me well across a few different projects. But Mountebank is not the only serious option, and on a Java heavy stack in particular, WireMock tends to come up just as often, sometimes more. This post is not about replacing Mountebank, it is about knowing when WireMock is the better fit, since the two tools solve overlapping problems in genuinely different ways. ...