How to Mock and Simulate JMS IBM WebSphere MQ with Traffic Parrot [Hands on Review]

Traffic Parrot, a service virtualization tool, hands-on Review Tutorial:

Traffic Parrot reduces software testing costs and helps testers deliver the product faster by using service virtualization, a practice also known as mocking or simulating APIs.

Mocking and simulating are important techniques that can help us in testing our applications in isolation.

Testing in isolation means moving away from complex test scenarios and involving multiple applications to scenarios that focus only on the applications that we are testing.

The terms Mocking and Simulating mean replacing a real service with a pretended one in which we can directly control the behavior of.

Traffic Parrot

WebSphere MQ with Traffic Parrot

In this Traffic Parrot review, we are going to explore how to use Traffic Parrot, a service virtualization tool that is opening doors for teams that work with JMS and would like to do mocking or simulation.

Why Service Virtualization?

These techniques will allow you to:

  • Test your application when its dependencies are not available.
  • Test scenarios that are usually too hard to reproduce.
  • Spend less time setting up test data.

Traffic Parrot simplifies JMS testing by providing you with a way to set up JMS test scenarios that would otherwise require the setting up of complex test data across multiple systems.

It supports IBM WebSphere MQ as well as Apache ActiveMQ, which in turn is a welcome addition to the JMS testing toolbox.

Problem Traffic Parrot is Solving

First, let’s discuss the various types of situations in which we would like to mock and simulate JMS messages.

A typical communication pattern is required to use an IBM WebSphere MQ broker with a request queue and a response queue:

  1. System A will send a request message to the request queue.
  2. The requested message will then be consumed by System B.
  3. After doing some internal processing, System B will respond by sending a response message to the response queue.
  4. Later, System A will consume the response message.

Systems Communcation

Here are a number of possible times that System B might be hard to work with for testing:

  • An API or the whole system may not exist yet.
  • Another tester could already be using it.
  • The test environment may be having some technical issues.
  • Setting up test data is hard or impossible.
  • Simulating error responses is impossible.

No BM MQ JMS responses

For these scenarios, we can simulate System B using Traffic Parrot so that System A can be tested in isolation. Traffic Parrot will pretend to be System B by consuming the requested messages and producing response messages accordingly.

Sending response messages to IBM MQ

Use Traffic Parrot to send JMS Response Messages

Now, let’s discuss a typical workflow using Traffic Parrot to simulate and mock the behavior of a system that receives and sends JMS messages. 

As a tester of System A, I would like Traffic Parrot to pretend to be System B by sending the response messages to System A. To achieve this, we need to configure Traffic Parrot to respond with a particular message in a particular queue. We will configure that with the Traffic Parrot browser-based user interface.

Simple mapping

Next, we put Traffic Parrot in replay mode to instruct it to start responding to the requested messages.

Replay started

And that’s it! As simple as that, we now have a fully functional JMS mock. System A can now be tested and we can change the response of Traffic Parrot (pretending to be System B) to suit our test scenario.

This could include the usual response messages and also the error responses that could be hard to reproduce using real data (e.g. an item is out of stock).

Advanced Features

Traffic Parrot has a number of advanced features that can be used to simulate complex behavior with little effort.

Let’s explore a few of those now.

The response messages are common and contain information from the requested message.

For example, perhaps System B is responding to a list of requested items and we need to mention each item in the response. We can use dynamic responses to achieve this in Traffic Parrot. The example below shows how we can do this for an XML message. Similar results are possible for JSON messages and raw text messages as well.

(Note: Click on the image for an enlarged view)

Complex mapping

The templating approach is very powerful. For example, we can:

  • Use the requested data in the response.
  • Add the current date/time in the response.
  • Generate random numbers in the response.
  • Looping over parts of the request in the response.

Testing Existing Systems with Traffic Parrot

While testing an existing system that has previously been tested only end to end with all of its dependencies present, it is common for there to be many types of messages that need to be configured while using service virtualization to test in isolation.

Traffic Parrot offers a record and replay functionality that helps us capture existing messages that we can later edit to suit our testing needs. Traffic Parrot does this by intercepting requests and responding to messages, pairing them together to form mapping, and later forwarding them to the usual destination.

Recording diagram

This is a powerful technique for quickly testing an existing system without having to invest a lot of time upfront to manually define mappings one by one. Instead, we can record traffic in a test environment and edit the captured mappings to suit our testing needs.

To learn more about how to do that, take a look at this JMS IBM MQ record and replay demo.

Closing Remarks

Traffic Parrot can help us to test an application without needing any assistance from the developers.

We are able to configure JMS behavior using a simple browser-based UI, which allows us to test our system quickly and easily in many different scenarios.

We also learned how Traffic Parrot can be used to record and replay traffic from/to existing systems, giving us a head start in setting up our initial JMS response messages for testing. This can help us while working with old systems that were not built with testability in mind.

Next stepsDownload Traffic Parrot service virtualization and try it for yourself. Watch this step-by-step getting started guide to learn the tool quickly.

Let us know if you have any queries using this tool.

Recommended Reading

1 thought on “How to Mock and Simulate JMS IBM WebSphere MQ with Traffic Parrot [Hands on Review]”

  1. Very Helpful information !


Leave a Comment