Friday, 17 July 2020

Traffic Parrot 5.15.0 released, whats new?

We have just released version 5.15.0. Here is a list of the changes that came with the release:


  • Traffic Parrot can now connect to IBM MQ queue managers via SSL channels. You can do this via Native IBM MQ. We have added two new ibm-mq-connections.json properties to support Native IBM MQ SSL connections:
    "sslCipherSuite": "TLS_RSA_WITH_AES_128_CBC_SHA",
    "sslPeerName": "OU=TP IBM MQ"
    To provide the server and client certificates you can add the following config to jvm.args:

Friday, 10 July 2020

Traffic Parrot 5.14.1 released, whats new?

We have just released version 5.14.1. Here is a list of the changes that came with the release:


  • A new property that allows to force logging Native IBM MQ message bodys as printable characters instead of UTF8


  • The Native IBM MQ messages can now contain UTF-8 characters, for example Arabic text
  • The Native IBM MQ logs are now correctly displaying UTF-8 characters, for example Arabic text
  • The JMS IBM MQ tutorial example fruit ordering system now supports UTF8 characters, for example Arabic text

Tuesday, 7 July 2020

Traffic Parrot 5.13.0 released, whats new?

We have just released version 5.13.0. Here is a list of the changes that came with the release:


  • New environment variable that allows configuring how long the startup scripts will wait for TP to start up use TP_STARTUP_WAIT_MILLIS, for example:
    test@test-pcs:~/Downloads/trafficparrot-no-jre-5.x.y$ export TP_STARTUP_WAIT_MILLIS=180000
    test@test-pcs:~/Downloads/trafficparrot-no-jre-5.x.y$ ./
    Picked up environment startup timeout in milliseconds 180000
  • A new property that allows to specify a replay Native IBM MQ script that will be run on startup


  • The SDK Workspace allows now for Native IBM MQ message transformers to specify an MQMessage directly. This allows for creating transforming proxies of messages. A sample has been provided in the SDK workspace.


  • Users were unable to update Native IBM MQ mappings in renamed files.

Saturday, 20 June 2020 Cannot run program "hostname": error=2, No such file or directory

"I am getting an error when starting Traffic Parrot < Cannot run program "hostname": error=2, No such file or directory>" - Senior Performance Engineer working for an Australian Bank

It looks like an operating system configuration issue. You are missing the "hostname" command.

To check if that is the case, please SSH to the container running TP and execute "hostname" in the shell.

To solve this issue, install "hostname" in your docker image. For example, add to your Dockerfile:

yum -y install hostname


apt install hostname

Tuesday, 9 June 2020

Is there a way to import requests and responses (either in JSON/TXT/XML format) to create virtual services?

"Is there a way to import request/response (either in JSON/TXT / XML format) and create HTTP and Native IBM MQ virtual services? Is OpenAPI specification the only way to create virtual services other than recording?" Senior Architect working for a global airline

For HTTP you can:
Traffic Parrot has support for the following formats to import HTTP:
  • WireMock 2.x mappings in ZIP format
  • Swagger 1.x and 2.x
  • OpenAPI 2.x and 3.x
  • RAML 0.8
For Native IBM MQ MQ you can:

Wednesday, 27 May 2020

Traffic Parrot 5.12.0 released, whats new?

We have just released version 5.12.0. Here is a list of the changes that came with the release:


  • New property that allows configuring how IBM® MQ queues will be accessed
  • New property that allows skipping logging message body for native IBM® MQ
  • Native IBM® MQ now respects the existing properties that allow for caching mappings in memory
  • You can now configure per connection to an IBM® MQ broker how many read and how many write connections to open. You do it in the ibm-mq-connections.json. For example:
    "readConnectionsToOpen": 5,
    "writeConnectionsToOpen": 5
  • The Native IBM® MQ mapping allows for configuring how many threads should be used to access the queue, for example:
    "receiveThreads" : 5,
    "sendThreads" : 1
  • You can define in the mapping how many messages the Native IBM® MQ connector will be keeping in memory at once, which will be relevant for scenarios when sending delayd messages, for example:
    "maxMessagesInProgress": 1000000
  • You can start the Native IBM® MQ replay with a script, for example:
    # This is a sample comment 1
    RequestQueueManager:'Request QM1'
    ResponseQueueManager:'Response QM1'
    # This is a sample comment 2
    RequestQueueManager:'Request QM2'
    ResponseQueueManager:'Response QM2'
  • Handlebar templates are cached allowing for better performance


  • There has been performance improvements made to the Native IBM® MQ connector. See the performance benchmarks for more details.
  • Native IBM® MQ response messages during a replay have the replyToQueueEmpty and replyToQueueManager set to the connected queue manager if they did not have any of these attributes set on the request message
  • Native IBM® MQ sends the queue manager name along with queue name when sending a message. This is applicable in scenarios with multiple queue managers set up in a cluster without the cluster sender and cluster receiver channels
  • Logging more runtime information on startup
  • Additional logging when connections to IBM® MQ fail

Thursday, 7 May 2020

What network config do I need to change when installing Traffic Parrot?

If you are just starting with Traffic Parrot and would like to know which network configurations need changing to use Traffic Parrot, please contact to confirm the current network setup and how we can help.

You can also have a look at the following setup as a starting point (click to enlarge)


Thursday, 30 April 2020

What is the "concurrent floating license"?

With Traffic Parrot (TP) floating licensing a limited number of licenses are shared among a larger number of users or environments over time.

When an authorized user or environment wishes to run the application they request a license from a central license server. If a license is available, the license server allows the application to run. When they finish using the application, or when the allowed license period expires, the license is reclaimed by the license server and made available to other authorized users.

Let us say, you are running the following configuration:
  • TP installed on 10 Jenkins Slaves (TeamCity build agents, etc) but at most 3 of them use TP at the same time
  • 1 TP instance installed and used in the performance testing environment where the tests are run overnight
  • 1 TP instance installed and used in the system testing environment where the tests are run during the day
So you use only 4 instances Traffic Parrot running inside the organisation at the same time.
So you need to purchase 4 floating licenses.

To help us determine how many licenses you might need, please answer these questions:
  • How many environments will you have where the TP will be running for long periods of time (24/7)?
  • How many build/pipeline runners (e.g. Jenkins salves) do you have?
  • How many developers and/or testers would use Traffic parrot on their laptops/desktops/VMs?
Then, to get a quote, please fill in the form 

Friday, 3 April 2020

What are the challenges you see with third party inbound and outbound testing when using IBM MQ queues?

"What are the challenges you see with third party inbound and outbound testing when using IBM MQ queues?" - Software tester working for a multinational enterprise.

Sometimes third-party systems can cause issues when testing your enterprise systems, for example:
  • The third-party system is not available 24/7 for testing, you need to schedule time on test environments as it is shared between many teams which result in the lower time to market
  • The third-party system does not allow for simulating error responses
  • The third-party test environment might not support the load you require for running your performance tests

In this case, you can use service virtualization or mocking tool to simulate the third party system.

Here is a sample tutorial for Traffic Parrot if you are using IBM MQ via JMS APIs.

Monday, 30 March 2020

Bestow has used Traffic Parrot gRPC mocks to deliver features faster to customers

After a thorough evaluation, Bestow Inc. selected Traffic Parrot's service virtualization and API mocking tool in April 2019 for their application development needs. In this case study, we will look at the details of their infrastructure, how they applied Traffic Parrot, and what issues they have come across.
  • Traffic Parrot is specifically designed to maximize the productivity of developers writing automated tests and to enable them to mock out microservices for local development. Their lightweight platform with gRPC support was a good fit for our Docker and Go-based development environment. They provided strong support during the POC and continue to track the rapid evolution of gRPC, acting as an effective extension to our team.
    Brian Romanko, VP Engineering at Bestow


Bestow has challenged industry assumptions with a new underwriting framework that provides affordable term life insurance in minutes instead of weeks. They use Traffic Parrot to unblock teams and allow them to work independently. Bestow uses Traffic Parrot gRPC mocks in their microservice CI regression testing suites to detect breaking changes in their microservice APIs.

Technology stack: Docker, GoLang and gRPC

The core technology they rely on includes:
  • Container-based infrastructure, running Docker in Kubernetes on GCP
  • Microservices in a variety of languages, including GoLang and Python
  • Microservices communicate using gRPC APIs, with API contracts defined in Proto files
Bestow colocated teams developing a microservice to encourage close communication. gRPC APIs connect microservices, which are sometimes owned by different teams. Bestow designs gRPC APIs using Proto files, which form the contract between microservices.

Problem: teams are blocked waiting for APIs

Starting more than a year ago, Bestow developed multiple microservices in parallel. For example, the Policy Administration team provided gRPC APIs for the Enrollment team to consume. This meant that developers on the Enrollment team were sometimes waiting for the Policy Administration team to deliver their microservice APIs before they could start working.
This led to blocked timelines between teams, which meant Bestow could not deliver at the fast pace required for their customers. It was urgent for Bestow to find a solution to allow the teams to work independently.

Solution: decouple teams by using gRPC mocks

Traffic Parrot was identified as a candidate for a gRPC API mocking solution that could help unblock the timelines between the teams at Bestow. After a two week technical evaluation by VP of Engineering Brian Romanko, it was clear that the open-source alternatives did not provide adequate capabilities and Traffic Parrot was chosen to fulfil Bestow development needs.
Teams at Bestow use Traffic Parrot to develop both sides of their gRPC APIs in parallel, without having to wait for the server code to be written before a client can be tested. They run automated test suites on their CI build agents, with Traffic Parrot running in a Docker container on the agent.

Wednesday, 25 March 2020

How to choose a service virtualization tool?

Most companies like to evaluate several tools before they commit to a purchase.

Typically they evaluate the service virtualization tools based on many factors such as:
  • Cost
  • Protocols and technologies supported
  • Features
  • Performance benchmarks
  • Support level

Here are a few additional technical questions might help decide which of the tools you are looking at is best:
  • Would you like to have a central team of administrators managing the new tool?
  • What kind of footprint would you like (RAM, disk usage, ...)?
  • What kind of licensing model would work best for your use case?
  • Do you need to source control of the virtual services and deployment scripts?
  • Are you looking for a tool that fits more the microservices architecture or a monolithic architecture?
These questions are based on:

Wednesday, 26 February 2020

How long will it take to create 100 virtual services or API mocks and how many people do I need?

“I would like to create API mocks for 100 HTTP SOAP/JSON and JMS Active MQ services. How much time will it take and how many people do I need on my team?” - Software Architect working for a software consultancy

This is a concern many of our clients face. We typically recommend rephrasing the question to include the problem description as well.

Key takeaways:

  • You must define the problem you are solving before you can start a service virtualization project
  • State clearly the value the service virtualization project is to deliver
  • Running a pilot project to demonstrate value is key
  • There are several key factors that influence the length and size of the project
  • Categorising services can help estimate the scope of the project

A significant portion of our customers engages in large scale service virtualization and API mocking projects that need to be managed accordingly. That means they would like to know what is required to complete the project: how many man-days, how many people and what hardware resources are needed.

The typical driver for those big projects is removing bottlenecks such as test data setup times or driving faster time to market.

What we typically recommend is to rephrase the problem in the context of the theory of constraints and narrow the scope down to “what is the amount of mocking we should do to solve the problem well enough so it's not a problem any more and we can focus on other development and testing priorities”.

So in other words, it might not be a good idea to aim to create the mocks for all services, it might be a better idea to decide what is the critical mass of mocks to create for the problem you are facing to go away so you can focus your efforts on other priorities.

An example of that would be a major UK bank that had an issue with setting up test data in the mainframe systems as it was done by an external team that took 2-3 weeks to prepare the data for every sprint’s testing efforts. Only a subset of those APIs was being used by the mobile application. That mobile application was being evolved quite rapidly compared to the other consumers of those APIs. The architects have decided to create mocks for a subset of the mainframe services only for a subset of their use cases. They have driven the efforts by the suite of mobile tests so that the automated regression suite of tests could be run against API mocks per sprint. This allowed them to reduce the complexity of the mocks because they did not have to account for other teams’ use cases and complexities.

Another example is a US insurance company that uses a third-party payment gateway service. They have created a mock that covered only a subset of the payment API features but allowed them to test all of their use cases of that service.

Having said all of that, the problem of scoping the project still remains. Let’s explore that in more detail.

The time will be different for every project and team but there are ways to estimate

The required complexity of the services or API mocks depends on the complexity of the services themselves and also on the complexity of the usage pattern of those services, e.g. how many test cases you run.

As discussed in How much time it will take to build/virtualize a simple, medium and complex service?:

  • A simple service depending on your team's maturity and setup will typically take a few minutes to a day
  • A medium service can take from a few hours to a few days
  • A complex service can take from a few days to a few weeks

Because of the uncertainty of how long building individual services will take we recommend that you run two activities in parallel:

  • Assign a small team or an individual to deliver the first virtual services to hit the first value realisation milestone
  • Assign a small team or an individual to estimate the size of the full project

Once that is done, you will have a better understanding of the complexity of the project.

One important point to notice is that if the value realisation milestone pilot project takes more than several weeks that means it might be too big, it should ideally be a couple of days to a few weeks. In case it’s too big, you might need to revisit your testing strategy and testing pyramid. If you have problems defining your value realisation milestone pilot project please reach out to us at and we will be happy to advise.

How to deliver the first value realisation milestone?

In order to prove that the API mocking and service virtualization approach is capable of a good ROI at your company, we recommend you assign a capable technical person or couple of people to realise the first milestone. Once that is done, they can share the findings and knowledge with the rest of the team.

The key requirements for the people involved in the first project:

  • Has worked on the project for at least 12 months already
  • A person that has experience running pilot projects
  • Good understanding of the business domain
  • Good understanding of the system under test
  • Good understanding of the technologies involved
  • Good communication skills
  • A pragmatic approach to problem-solving

We recommend choosing a value realisation milestone that is clear to the business. Here are a few examples of value realisation milestones you could look for:

  • Reduce test data setup time from 2 weeks to 1 minute by using pre-configure Traffic Parrot API mocks instead of waiting on the test data setup team to deliver new test data in the SIT environment mainframe systems
  • Allow for simulating several typical error responses observed in production for one of the services which will result in better regressions testing coverage and no production bugs in that area
  • Have a look at the typical problems solved by service virtualization/mocking/stubbing for more ideas on how to find a value realisation milestone

After going through this exercise, you might have a few candidates for a good value realisation milestone pilot project. The best project to use out of those is the least complex one that takes the least amount of effort; pick the low hanging fruit. You can then demonstrate the ROI fast, and onboard the team to the new testing approach. Once the team is familiar with the new approach to testing, you can tackle more complex projects.

How to estimate the size of the project?

To help you estimate the size of the full project we advise to:

  • Categorise complexity of services
    • Low complexity service
    • Medium complexity service
    • High complexity service
  • Categorise complexity of the individual tests and how they use the services
    • Low complexity test
    • Medium complexity test
    • High complexity test
  • Categorise the value of individual tests by how much value would be captured if those tests started using mocks instead of the real services
    • Little value
    • Moderate value
    • High value
  • Categorise by the rate of change of APIs and tests
    • Low change rate
    • Medium change rate
    • High change rate
  • Categorise services and tests by production critical issue risk
    • Low impact on production incidents
    • Medium impact on production incidents
    • High impact on production incidents

This is to give you an idea of what is involved in delivering the project and help prioritise work. For example, high complexity tests that use high and medium complexity services will take orders of magnitude longer to deliver than low complexity tests that use low and medium complexity services. You might find low hanging fruit, like high-value and low complexity tests onboard to use virtual services as a priority. The categorisation will also help you prioritise which services and tests to deliver next.

For example, a simple user login test might use one simple service and which is simple to mock, but delivers a lot of value because if the user cannot log in you cannot run 70% of the other test cases.

Another example could be a payment test, which is medium in complexity but is critical to the business as if the payment does not work then the company does not make money.

Once you have the categories identified, you can assign an estimate S (small), M (medium), L (large) to each task and take the rough estimate we have provided in the article above. While you work on the tasks one by one and deliver S, M and L tasks you will get more visibility on how long S, M and L tasks take to complete in your environment and increase the accuracy of your overall estimate. You can then assign more people to the project if needed.

We would be happy to assist you in your estimations efforts, please reach out to us by emailing us at

Should I deliver mocks per-service or per-test?

Depending on the complexity of your tests and the complexity of the services you will be mocked, you might drive the change by implementing mocks for services or mocks for tests.

For example, a UK retail bank used a third party threat detection HTTP service that has a simple API, which takes several input parameters and returns a risk score. This service usage pattern remains the same regardless of the complexity of the test cases that rely on the connectivity to this service. The developers have decided to implement a dynamic mock service that depending on the request data returns a predefined risk score. This allowed it to be re-used in many tests.

Another example, a UK challenger bank had a user onboarding test that required connectivity to over 20 complex third-party and mainframe services. Those services were used not only in this test but also in other tests not related to user onboarding. The team decided to implement the mocks per-test not per-service as it reduced the complexity of the solution.

We would be happy to help you assess how to approach the mocking on a case by case basis, feel free to reach out to for more details.

Monday, 17 February 2020

Why do I have to create a new test environment for service virtualization?

"Why do I have to create a new test environment for service virtualization? Will it be more work for us to test now in two environments?" - Test Architect at a UK test consultancy

Create a separate environment for a new testing phase is a standard industry approach for implementing API mocking. This short case study provides an example of how it has been at a company we have worked with.

A global media company was developing a new product to be released to the market in 7 months time. The testers and developers were using a third party API for mobile number porting. The communication with the service was done asynchronously using files.

There was an issue with that API because they had to wait for 24 hours for requests to be processed and responses returned.

The developers and testers decided to take control of their testing schedule by mocking the third party service. They did this by introducing a new environment where they tested with service virtualization. They used Traffic Parrot technology to create API mocks.

The testers were happy to have two environments because it allowed them for more predictability and control over their test cases when testing with mocks. They used the integrated environment only when integrating with new APIs or changing user journeys significantly.

The result was that they were able to save 3 or more days a week in lead time for product development.

Monday, 27 January 2020

How to combine microservices and BigData?

"I've just joined a company and the architects love microservices but the developers love Big Data solutions. Do they mix? Can you point me in the direction of where I can read more about marrying the two together?" - Big Data Engineer working for a UK financial startup.

Microservice architectures are a tool to solve a specific problems an organisation might have. If you have problems that can be solved by using microservice architectures, generate 2-3 options and if the microservice route looks most promising, go for it.

Our general recommendation would be to focus on the problems you have to solve and the constraints you are working with, generate a few options and possible solutions and choose the one that seems most promising.

There will be certain scenarios where BigData and microservices will work well together, and others where they will not make sense. We would have to know more details to be of further help, please email contact us to schedule a call to discuss your specific requirements.

We recommend reading Sequoia's Guide to Microservices and Martin Fowler's blog on microservices as a good starting point to problems microservice architectures help solving.