What it is

WireMock is an open source tool for mocking HTTP services, started in 2011 as a Java library by Tom Akehurst and now spanning multiple programming languages and technology stacks. It lives in the Java ecosystem, is licensed under Apache-2.0, and is published at wiremock.org. The project can run as a library or client wrapper in many languages, or as a standalone server, and it supports several approaches for creating mock APIs: in code, via its REST API, as JSON files, and by recording HTTP traffic proxied to another destination.

The concrete problem it solves is the instability and unavailability of the HTTP services that tests and development environments depend on. WireMock creates stable test and development environments, isolates a codebase from flaky third parties, and simulates APIs that do not exist yet. Its rich matching system allows any part of an incoming request to be matched against complex and precise criteria, and responses of any complexity can be generated dynamically through a Handlebars based templating system. Numerous extension points and comprehensive APIs make it straightforward to integrate into an existing workflow.

Key capabilities

• HTTP response stubbing, matchable on URL, header and body content patterns.
• Configuration through a fluent Java API, JSON files, or JSON over HTTP.
• Record and playback of stubs, including recording HTTP traffic proxied to another destination.
• Request verification against the stubs that were registered.
• Fault and response delay injection for exercising error and timeout paths.
• Per-request conditional proxying, plus browser proxying for request inspection and replacement.
• Stateful behaviour simulation and extensibility through documented extension points.

Who uses it and how

• Teams running WireMock inside unit tests, where it starts and stops alongside the test suite.
• Teams running it as a standalone process or as a container, so a shared mock API serves several services or developers.
• Teams recording traffic from a real upstream and replaying it as stubs, to remove dependence on a live third party.
• Teams defining stubs as JSON files or posting them over the REST API, keeping mock definitions outside application code.
• Teams simulating APIs that do not exist yet, so client work can proceed before the upstream is built.

Getting started

WireMock can run in unit tests, as a standalone process, or as a container, and can be used as a library or client wrapper in many languages. Full documentation is at wiremock.org/docs, and the community Slack at slack.wiremock.org hosts a #help channel for questions.

When to use it — and when not to

WireMock open source is the free tool that powers WireMock Cloud, the paid offering the README points to for advanced capabilities such as OpenAPI, dynamic state, and data sources, so teams needing those features are directed to the hosted product rather than the open source build. A self-hoster runs the standalone server or container and maintains the stub definitions, JSON files, and any recording or proxying configuration themselves. The project carries 503 open issues and ships a japicmp-based report comparing each build against the last 3.x release for binary-incompatible changes to @PublishedAPI classes, so upgrades across

/breaking-change-report

./gradlew :wiremock-core:japicmp