Traffic Parrot, a service virtualization tool, hands-on Review Tutorial:
Traffic Parrot reduces software testing costs and help 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 the complex test scenarios and involving multiple applications to the scenarios that focus only on the application that we are actually testing.
The terms Mocking and Simulating actually mean replacing a real service with a pretended one in which we can directly control the behavior of.
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.
What You Will Learn:
These techniques will allow you to:
Traffic Parrot simplifies JMS testing by providing you with a way to set up JMS test scenarios that would otherwise require 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.
First, let’s discuss the various type of situations under which we would like to mock and simulate JMS messages in.
A typical communication pattern is required to use an IBM® WebSphere MQ broker with a request queue and a response queue:
In this situation, there are a number of possible times that System B might be hard to work with for testing:
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 request messages and producing response messages accordingly.
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 on a particular queue. We will configure that with the Traffic Parrot browser-based user interface.
Next, we put Traffic Parrot in replay mode to instruct it to start responding to the request messages.
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 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).
Traffic Parrot has a number of advanced features that can be used to simulate complex behavior with a little effort.
Let’s explore a few of those now.
It is common for the response messages to contain information from the request message.
For Example, perhaps System B is responding to a list of request 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)
The templating approach is very powerful. For example, we can:
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 record and replay functionality that helps us to capture existing messages which we can later edit to suit our testing needs. Traffic Parrot does this by intercepting request and response messages, pairing them together to form a mapping and later forwarding them to the usual destination.
This is a powerful technique for quickly testing an existing system without having to invest a lot of time up front to manually define mappings one by one. Instead, we can record the 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.
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.
Let us know if you have any queries using this tool.