Part of Switching from another tool, the hub for every migration page.
« Back to documentation homeTraffic Parrot embeds a fork of WireMock and is WireMock-compatible. If you already use WireMock, the artefacts you have built carry over directly:
bodyFileName
response attribute work exactly as they do in WireMock.The How to migrate WireMock to Traffic Parrot tutorial imports a sample WireMock project end to end, and its What behaves differently section lists what to check once your mappings are loaded.
Because the request matching, request-to-response mapping format, and response templating come from the embedded WireMock fork, your existing stub definitions keep their meaning. Traffic Parrot then runs them as a standalone server with a web user interface, recording, and additional protocols layered on top.
For the details of how Traffic Parrot loads, imports and serves WireMock mappings, see
Import and export HTTP mappings
(including importing a WireMock ZIP) and
File-backed responses with bodyFileName and the __files directory.
A short, downloadable getting-started package is also available on the
WireMock getting started package page.
Because Traffic Parrot is WireMock-compatible, adopting it does not mean throwing away what you have built; it means keeping your HTTP stubs and adding capabilities WireMock does not set out to provide. If you are deciding whether to adopt or migrate, these are the differences that matter most:
Everything you already rely on for HTTP (request matching, the request-to-response mapping format and response templating) continues to work, because it comes from the embedded WireMock fork. The additions above sit on top of that familiar foundation.
WireMock focuses on HTTP. That is exactly what you want when the system under test only speaks HTTP, but most real systems do not. A service might receive an HTTP request, publish a message to a queue, and read from a mainframe. To test it end to end with WireMock alone, teams typically bolt on a separate stubbing or mocking tool for each non-HTTP dependency, each with its own configuration style, its own lifecycle, and its own way of matching requests and templating responses.
Traffic Parrot removes that fragmentation. It virtualises HTTP and the other protocols your system depends on in one standalone server: one tool to install, one running instance to share across the team, and, crucially, one mental model. The same request-matching and response-templating concepts you already know from WireMock apply across every protocol, so moving from stubbing an HTTP endpoint to stubbing a queue or a gRPC method is a small step, not a new tool to learn.
The protocols Traffic Parrot virtualises, in addition to HTTP, are:
For a WireMock user, the practical effect is that you keep your HTTP stubs and gain messaging, mainframe-queue and file virtualisation without adding more tools to your test stack: one running server, one configuration approach, one place to inspect what the system under test actually sent.
The biggest difference for a WireMock user is the model. The WireMock library is often run embedded inside a test process, started by a JUnit rule or extension, bound to a random port, and driven through a Java DSL. Traffic Parrot runs as a standalone server rather than an in-process library: you start it once, point your system under test at it, and drive it through its web user interface and admin API. From a JUnit test you start it in a container with the Testcontainers module, whose TrafficParrotClient stubs, verifies and resets over the admin API.
A standalone server is an advantage rather than a missing feature: one running instance can be shared across a whole team and across test runs, configured the same way every time, inspected live in the GUI, and reused outside of JUnit (manual testing, demos, performance runs, and non-JVM clients). The table below translates common WireMock embedded API habits to their Traffic Parrot equivalent.
| WireMock (embedded library) | Traffic Parrot (standalone server) |
|---|---|
@WireMockTest / WireMockExtension / @Rule to start a server per test |
Start the Traffic Parrot server once and keep it running. You can start it from the GUI / downloaded distribution, from the trafficparrot-maven-plugin start/stop goals, from JUnit with the Testcontainers module, or as a container. The server is then shared by all of your tests rather than re-created for each one. |
Random port assigned at startup, then read back in code (for example wireMockServer.port()) |
A fixed, configured port. The virtual service listens on
trafficparrot.virtualservice.http.port (default 8081),
so your system under test always targets a known address. See the
configuration reference for this property and
how to override it.
|
verify(...) DSL to assert that requests were received |
The request journal, viewable in the GUI, and available over the admin API:
GET /api/http/requests lists received requests (it returns the same
journal as WireMock's /__admin/requests), and
POST /api/http/requests/count returns the match count for a criteria,
which is the equivalent of a verify count assertion.
|
reset() between tests |
DELETE /api/http/requests clears the request journal,
POST /api/http/__admin/scenarios/reset returns stateful mappings to
their starting state, and DELETE /api/state clears key-value state,
giving you a clean starting point between tests without restarting the server.
Mappings are files on the server and stay as they are.
|
The admin endpoints above are served on the Traffic Parrot management port
(localhost:8080 by default), the same port that hosts the GUI, not the
stub-serving port your system under test calls. WireMock's own /__admin API
stays on the virtual service port, 8081.
The concepts you rely on in WireMock map onto these Traffic Parrot pages:
trafficparrot.virtualservice.http.port, default 8081).
Still weighing up the wider field rather than migrating a specific WireMock setup? This page deliberately stays a compatibility and migration reference. For a comparison across tools (protocols, deployment, licensing and how each one fits an as-code workflow) read Best Service Virtualization Tools.