Most testers have at least heard of the OWASP Top 10, the well known list of the most critical web application security risks. Fewer have spent real time with its sibling list, the OWASP API Security Top 10, which exists because APIs fail in ways that are genuinely different from traditional web applications, and a checklist built for server rendered pages with form submissions misses most of what actually goes wrong in a REST API sitting behind a mobile app or a partner integration. ...

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. ...

Lately, it feels like we’ve crossed into a totally new era with AI tools. Over the past few months, my focus has shifted from simple code auto-completions to playing around with Autonomous Agentic Workflows. Instead of just having an assistant that finishes a line of code, an agent acts more like a goal-oriented script. You give it a high-level target, and it can plan out multi-step actions, check the results, and adjust its approach on the fly. ...

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. ...

In the previous post, we walked through what happens when a contract genuinely breaks, and how tagging and versioning give both teams a precise way to reason about it. This last post in the series pulls every piece we have built, consumer tests, the broker, provider verification, and can-i-deploy, into one coherent pipeline view, so it is clear how this actually runs day to day rather than as a sequence of separate manual steps. ...

In the previous post, can-i-deploy gave checkout an automated gate that blocks a deploy when payment has not verified the current contract. That check is only as good as the version history behind it. This post looks at how Pact tracks that history, and what actually happens in the broker when a contract changes in a way that breaks an existing consumer. Every Contract Publish Is a New Version Each time checkout runs pact:publish, it does not overwrite the previous contract. It adds a new version, tied to whatever identifier you passed in, normally a git commit hash. The broker keeps every version, along with which provider versions have verified each one. This is what makes can-i-deploy meaningful. It is not asking “has this contract ever passed,” it is asking “has this specific version passed.” ...

In the previous post, both checkout and payment started publishing contracts and verification results to a shared Pact Broker. The broker knows exactly which version of payment has verified exactly which version of checkout’s contract. What it does not do on its own is stop anyone from deploying a version that has not been verified. That is what can-i-deploy is for. The Question It Answers Before checkout deploys a new version to production, there is one question worth asking automatically rather than trusting someone to remember it. Has every provider checkout depends on already verified this exact version of the contract. If the answer is no, the deploy should not happen, full stop. ...

In the previous post, payment verified checkout’s contract by reading it from a local folder path. That works for a demo, but it does not scale. The provider team should not need a copy of the consumer’s build output sitting on disk to run their tests. This is what the Pact Broker exists to fix. What the Broker Actually Does A Pact Broker is a small standalone service that stores contracts, tracks which versions of which services have verified which contracts, and exposes that history through a web UI and an API. Instead of checkout emailing a JSON file to payment, checkout publishes its contract to the broker after every build, and payment pulls the latest version from the broker when it runs verification. ...