Your HTTP mocks work. The trouble is the part of your test suite that never touches HTTP. An order service waits on a reply over an IBM® MQ queue, a settlement check reads a SWIFT MT message, a trade feed speaks FIX. Your HTTP mocking tool has nothing to connect to, so those tests wait for a real queue manager that is never free when you need it. You mock a non-HTTP protocol the same way you mock HTTP: simulate the dependency from its message contract and test against the simulation. The hard part is the tool. To mock IBM MQ and other non-HTTP protocols you need one that speaks the protocol, and that is where HTTP-only tools stop.
HTTP is request and response over a URL. A mock listens on a port, matches each request on its method, path, headers and body, and returns a hardcoded or generated response. To test against it you point the client at the mock's address instead of the real one. The dependency lives at an endpoint you control, so swapping in a stub is a one-line change.
IBM MQ and JMS do not work like that. The dependency is reached through a broker (a queue manager), not a URL. One system puts a request message on a request queue; the other consumes it, does its work, and puts a reply on a response queue. The first system then reads the reply. There is no endpoint to point the client at instead. A file-based dependency works the same way: a file dropped on an SFTP or FTP server, picked up, and answered with another file. An HTTP mocking tool has no concept of a queue, a queue manager, or a file drop, so it cannot take the dependency's place.
There are two ways to replace a messaging dependency, and they are not interchangeable. The difference is where the test double sits: inside your test's own process, or out across the network where the real protocol runs.
An in-process mock replaces an object inside the test's own process, in whatever language that process runs. Every language has a framework for it: Mockito in Java, Moq in .NET, Python's built-in unittest.mock. Each creates a test double and lets you stub its responses and verify how it was called, all in memory. You point it at the interface in your own code, the messaging client your service calls or the gateway behind it. The real IBM MQ client, the serialisation and the queue manager never run.
A system simulator sits out on the network and speaks the protocol. The system under test connects to it over the real transport, so the actual client library, the serialisation and the connection all run against a simulated dependency. You are no longer testing your Java code in isolation; you are exercising the real IBM MQ or JMS integration, with a simulator standing in for the system on the other end.
The test pyramid decides most of this for you. A unit test wants speed and isolation, so an in-process mock is the right tool: no broker, no network, milliseconds per test. An integration or component test needs confidence that the real protocol integration works; that is a job for a system simulator over the wire. An end-to-end, system or acceptance test runs against the deployed application as a black box, often in a process you cannot reach into and sometimes not even on the JVM. An in-process double is not an option at all. There, the over-the-wire system simulator is the only one of the two that fits. A performance test runs against the deployed application too, so it needs the same system simulator, and adds one more demand: the simulator must sustain the load and answer at realistic response times.
The pyramid is not the only model for balancing a test suite. For microservices, Spotify's testing honeycomb argues for the opposite emphasis: fewer unit tests and a large middle of integration tests. Its reasoning is that most of a service's complexity is in how it interacts with others, not in the service itself. Read that way, the over-the-wire system simulator is not a fallback for a few unavoidable integration tests. It is what much of the suite runs against.
| Approach | What runs in the test | What it does not exercise | Test phase it fits | Who reaches for it |
|---|---|---|---|---|
| In-process mock (e.g. Mockito) | Your code, with the Java client interface replaced in memory | The IBM MQ client, queue manager, serialisation and wire format | Unit tests | Developers, local testing |
| System simulator over the wire | The real protocol client and serialisation, against a simulated dependency | The real dependency's business logic; for IBM MQ and JMS a broker must still run in the test environment | Integration, component, system, acceptance, performance | Developers in CI, QAs in system test |
For a developer, the test phase decides the mocking level. Mockito is the fast default for unit tests of your own code. When a test has to exercise the real IBM MQ client, or it runs in a CI integration stage, the over-the-wire system simulator earns its place. A QA or test lead rarely has the second choice: you cannot inject an in-process double into an application that is already built and deployed. For system, acceptance and performance tests the protocol-native system simulator is the tool, because it is the only one that works from outside the application.
| Test phase | What to use | Why it fits |
|---|---|---|
| Unit test of your own code | In-process mock (e.g. Mockito) | Speed and isolation: no broker, no network, milliseconds per test |
| Integration or component test in a CI stage | System simulator over the wire | The real IBM MQ client, the serialisation and the connection all run |
| System or acceptance test against the deployed application | System simulator over the wire | The only one of the two approaches that works from outside the application |
| Performance test against the deployed application | System simulator over the wire | Sustains the load and answers at realistic response times |
The mechanics differ by protocol, but the pattern is the same in each case: the system simulator connects over the real transport, matches the incoming message on its content, and generates the response.
JMS is the Java API for messaging; brokers such as ActiveMQ and IBM MQ expose it, and RabbitMQ offers a JMS client, so the same JMS code can talk to any of them. You mock a JMS or IBM MQ dependency by connecting a system simulator to the broker, consuming the request message from one queue, and sending a response to another, matched by message content. Traffic Parrot covers JMS over ActiveMQ, RabbitMQ and IBM MQ, and native IBM® MQ for MQ versions 7.5, 8 and 9. The step-by-step instructions are in the JMS and IBM MQ tutorial, which uses IBM MQ Advanced for Developers, free for development use, in Docker.
SWIFT MT and FIX are message formats, not transports. A SWIFT payment or a FIX order arrives over a carrier, often IBM MQ, JMS or a file, and the content is a structured message of tagged fields. To simulate one, you match the incoming message on a specific field (by tag number) and generate the response fields you need. Traffic Parrot matches FIX and SWIFT MT at field level over IBM MQ, JMS and file transfers, so a settlement or trading test can assert on the exact tags it depends on without the real counterparty.
A file-transfer dependency drops a file and expects one back. Mocking it means watching the location the system writes to and returning a response file in the format the consumer reads. Traffic Parrot's file transfer support covers local file systems, FTP and SFTP. An overnight batch that pulls a partner file can run in a test, with Traffic Parrot supplying that file instead of the partner.
gRPC looks like it should be in scope for an HTTP tool, and usually is not. It is Protocol Buffers over
HTTP/2, not JSON over HTTP/1.1,
with binary framing and streaming calls, so a
plain REST mocking tool cannot read or answer it. You mock gRPC with a tool that
loads the .proto service definition and speaks the binary protocol.
Traffic Parrot supports gRPC unary, server-streaming, client-streaming and
bidirectional-streaming calls; the gRPC tutorial walks
through one.
The popular open-source mocking tools grew up around HTTP, and a few reach past it. The table compares the four you are most likely to consider for non-HTTP work, with Traffic Parrot's released coverage alongside for reference. The last column marks where each open-source tool reaches its limits, and a commercial tool is applicable.
| Tool | Protocols | Deployment | Licensing / cost | Primary use | When a vendor is the faster route |
|---|---|---|---|---|---|
| WireMock | HTTP and HTTPS; gRPC and GraphQL via extensions; WebSocket in the 4.x beta | Embedded library or standalone JAR | Apache 2.0 | Java teams writing JUnit stubs over HTTP | Reaches HTTP, gRPC and GraphQL. For IBM MQ, JMS, files or FIX and SWIFT, a commercial tool is the faster route. |
| MockServer | HTTP and HTTPS, plus SOCKS proxy; event-broker mocking via AsyncAPI (Kafka, MQTT and publish-only AMQP/RabbitMQ) | Embedded library, standalone, Docker | Apache 2.0 | HTTP mocking and proxy recording | No IBM MQ or JMS; its messaging is AsyncAPI event brokers, not the IBM MQ or JMS wire protocols. For those, a commercial tool is the faster route. |
| mountebank | HTTP, HTTPS, TCP and SMTP built in; more via community extensions | Standalone Node.js process | MIT | Over-the-wire test doubles driven from any language | TCP is a raw text or binary stream you frame yourself. For native IBM MQ or JMS a commercial tool is the faster route. |
| Microcks | REST, SOAP, GraphQL, gRPC; async via AsyncAPI (AMQP, MQTT and other event brokers) | Kubernetes Operator, Helm, Docker Compose | Apache 2.0 | Spec-first mocks from OpenAPI, gRPC and AsyncAPI | Broadest async coverage of the four, but no IBM MQ, JMS, FIX, SWIFT or SFTP. A commercial tool reaches those. |
| Traffic Parrot | HTTP(S), JMS over ActiveMQ, RabbitMQ and IBM MQ, native IBM® MQ, gRPC, Thrift, file transfer over local, FTP and SFTP; FIX and SWIFT MT field matching | One self-contained download; laptop, CI, Docker or Kubernetes | Concurrent floating licence | Tests that depend on IBM MQ, JMS, gRPC, files or FIX and SWIFT formats | If your services stop at HTTP, a five-line WireMock OSS stub does the same job. |
All product and company names are trademarks or registered trademarks of their respective owners. Traffic Parrot is not affiliated with, sponsored by, or endorsed by any of the other vendors listed. Protocol coverage reflects each project's public documentation as of 8 July 2026; corrections welcome.
WireMock is the safe default for an HTTP API and reaches gRPC and GraphQL through extensions. MockServer adds AsyncAPI event-broker mocking. Microcks has the broadest asynchronous coverage of the four. Mountebank will carry a raw TCP stream, though you frame the bytes yourself. Not one of them mocks IBM MQ or JMS today, and none covers FIX, SWIFT or file transfers. That is where an open-source shortlist for messaging work reaches its limits. For the full comparison across sixteen tools, commercial ones included, see the best service virtualization tools; this piece is about the technique, not the comparison.
Consider a software house that builds systems for government projects, integrating over IBM MQ. Before it changed approach, validating each test case by hand took at least 30 minutes, and sometimes up to two days when it meant coordinating with external teams to line up the MQ services. The dependency was real, so the test was only as available as the systems behind it.
Two limitations belong on the scorecard before you rely on Traffic Parrot for messaging work.
The released set covers the protocols in the table above. Some newer messaging technologies are offered only through the Traffic Parrot beta programme, not as shipped features. Check the current features list before you commit: for a generally available protocol you are ready to start. For one still in beta, the workaround is to join the programme rather than assume the protocol has shipped.
To seed a mapping by recording, the real dependency has to be reachable that one time so its messages can be captured. Where no environment is available, you define the mapping from the contract instead, filling in the request queue, response queue and message format from the documentation, exactly as the JMS and IBM MQ tutorial does. For the broader build-versus-buy limitations, such as user management and on-screen workflow customisation, see "What Traffic Parrot does not do" in the tools comparison.
It depends on the test. For a unit test, an in-process mock such as Mockito replaces the Java messaging client in your code, so nothing connects to a queue manager at all. For integration and system tests, a system simulator takes the place of the system you depend on, but the messages still flow through a queue manager. You do not need the production one: IBM MQ Advanced for Developers in Docker, free for development use, is enough to run those tests locally.
For unit tests, often yes. Mockito replaces the interface in your Java code, such as a JMS
MessageProducer or your messaging gateway, inside the same JVM. It is
fast and needs no broker. What it does not do is exercise the real IBM MQ client,
the serialisation or the queue manager, so it cannot catch problems in the actual
protocol integration. For that you need a system simulator that speaks the protocol
over the wire.
With HTTP you point the client at a mock server on a URL and match on method, path and body. A message-based dependency has no URL. It is reached through a broker: your system puts a request message on a queue and waits for a reply on another. To mock it you connect a system simulator to the same broker, match the request message by its content, and send the response message back on the reply queue.
No. WireMock mocks HTTP and HTTPS, with gRPC and GraphQL through separate extensions and WebSocket support in its 4.x beta. Its own documentation lists no IBM MQ or JMS support. For an HTTP API it is a widely used choice that does the job. For IBM MQ, JMS or other messaging protocols you need a tool that speaks them, such as Traffic Parrot.
SWIFT MT and FIX are message formats, not transports. They travel over a carrier such as IBM MQ, JMS or a file. You mock them by matching the incoming message on its field content (by tag number) and generating the response fields. Traffic Parrot matches FIX and SWIFT MT at field level over IBM MQ, JMS and file transfers, so a settlement or trading test can assert on the exact fields it depends on.
Not always. If your services stop at HTTP, an open-source tool like WireMock does the job. Some open-source tools reach further: MockServer and Microcks mock event brokers, and mountebank carries raw TCP. None of them mocks IBM MQ or JMS today. For those protocols, or for FIX, SWIFT and file transfers, a commercial tool that speaks them natively is the faster route.
If you are a developer, start with Mockito in your unit tests. Reach for an over-the-wire system simulator when a test has to exercise the real IBM MQ client or runs in a CI integration stage. The JMS and IBM MQ tutorial walks through it with IBM MQ Advanced for Developers in Docker. If you are a QA or test lead, list your non-HTTP dependencies first. For system, acceptance and performance tests, use a protocol-native system simulator; it is the one place where HTTP mocks and in-process doubles both stop. If you are an architect weighing build versus buy, score protocol coverage, deployment and licensing against your context. The best service virtualization tools comparison lays out the trade-offs. You can download a free trial when you want to try it against your own queues.
Whichever way you are leaning, talk to the vendors. Traffic Parrot is always happy to help you choose the right tool, whether that is open source, our own commercial simulator, or a combination of the two; just contact us.