Traffic Parrot 5.9.0 released - what's new?

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

Features

• Improvements to gRPC mappings list user interface:
  • Edit mapping tags that can be used to organize and search mappings
  • Added new tags column which is hidden by default

Fixes

• WireMock compatible HTTP APIs are now hosted on both:
  • http://localhost:8080/api/http/__admin/*
  • http://localhost:8080/api/http/*

  This means that the standard WireMock client libraries can be used when connecting to the API port e.g. when using WireMock.configureFor("localhost", 8080, "/api/http");

  Custom HTTP clients or a browser may continue to drop the /__admin section of the path so that API calls such as http://localhost:8080/api/http/mappings can be made

Traffic Parrot 5.8.0 released, what's new?

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

Features

• Improvements to gRPC mappings list user interface:
  • Added sorting to columns
  • Added a button to pause auto reload
  • Added a button to select which columns to display
  • Added two new columns which are hidden by default: id and name

Fixes

• Pause gRPC mappings list auto reload when highlighting text so that it is possible to highlight and copy text without the auto reload clearing the highlight
• Allow spaces in gRPC mapping file name template

Traffic Parrot 5.7.3 released, what's new?

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

Features

• gRPC mapping file name templates when saving mappings via the UI can now be customized with the following properties:

  #
  # Template used for gRPC mapping file names
  #
  # Available properties:
  # {{ mapping.id }}
  # {{ mapping.package }}
  # {{ mapping.service }}
  # {{ mapping.method }}
  # {{ mapping.isSuccess }}
  # {{ mapping.status.name }}
  # {{ mapping.status.code }}
  #
  # Available commands:
  # {{ countGrpcMappings package=mapping.package service=mapping.service method=mapping.method success=true offset=1 format='%02d' }}
  trafficparrot.virtualservice.grpc.saved.mapping.file.name.template={{ mapping.package }}.{{ countGrpcMappings package=mapping.package offset=1 format='%02d' }}.{{ mapping.service }}-{{ mapping.method }}[{{ mapping.status.name }}]
  trafficparrot.virtualservice.grpc.saved.mapping.file.name.collision.suffix.template=-{{ mapping.id }}
                                          

• When editing a gRPC mapping in the UI you can now choose whether to keep the existing file name or generate a new one according to the template properties when the mapping is saved

How to return different responses for the same URL when mocking REST HTTP APIs in Traffic Parrot

Typical problems solved by service virtualization/mocking/stubbing

In the first chapter of our tutorial series, we have a section that covers some of the typical problems that a service virtualization/mocking/stubbing approach addresses.

Do you experience similar problems? Please email us at consultation@trafficparrot.com to schedule a call where we can discuss your requirements.

Here are several of the more typical problems testers will experience while testing web applications, mobile applications, legacy systems and APIs and how service virtualization can help with solving them.

• Too much pressure on the testing team and not enough time to test

  This is a common problem and service virtualization alone will not fix it, but it is an essential part of the solution. If you can utilize service virtualization in your builds and pipelines you can have more confidence in your release cycle. The focus changes from trying to test everything to testing what could be at risk of having issues. These kinds of checks can give you a quick health status of the application, or a piece of it, without dedicating a lot of testing time. Quick feedback means quick wins overall.

• Testers being blocked by other teams not delivering APIs on time, leaving them unable to test

  In this case, you can use virtual services to simulate the non-existing API. If there are business requirements or documentation, you can create virtual services based on them to use until the real service is available to test. After you verify the system works in isolation according to your expectations, you can wait for the dependent API to be ready and do integration testing using the same tests. This is an example of using TDD for integration testing.

• Hard to reproduce production bugs resulting in frustration and time loss

  Test data and complex interactions with backend and third party systems can cause issues reproducing bugs found in production. Issues with setting up test data in multiple systems simultaneously, simulating error messages or simulating protocol issues are hard to accomplish tasks getting in the way of easy reproduction of the environment where the bug was found in production. Fortunately, complex environments like these and many others can be simulated with virtual services, allowing for more flexibility and peace of mind when reproducing bugs.

• Creating test data is complex and takes time, slowing the testing team down

  Often when you test old systems you have to wait for test data to be created, sometimes it’s even impossible to create the test data you need (especially in third party systems). Also, backend and third party systems can be hard to set up to return error responses, or throttle network responses, on demand. The solution is to use virtual services which are under your control, so you can set up any type of test data on demand.

• Scheduling time on test environments resulting in inefficient use of tester’s time

  Especially large banks with old mainframe systems experience this issue where the test environments are costly to create, so there is a limited number of them shared across many testing teams and projects. Those old APIs almost never get changed but they are included in many test plans, so you have to schedule time on those environments to run your tests. You can simulate the API that never changes with virtual services and test your application under test more often without having to wait for the API availability. It is also less likely to impact other teams by burning through their test data causing further delays.

• Cost of third party test transactions can complicate testing efforts

  In most cases, those paid APIs are very simple in nature and very rarely change. The cost of accessing third party APIs can complicate performance testing efforts as well. Simulating them using virtual services can reduce the third party transaction costs.

• Unreliable performance tests

  When you performance test many components simultaneously, it is often challenging to pinpoint the code change that causes a performance issue. The feedback loop is too large, and you are testing too many moving parts at one time. You ideally want to test small code releases in isolation and a limited number of components. That will ensure that if you see a degradation in performance, you can quickly point to a code changeset that was likely the cause. To run performance tests in isolation, you need virtual services. Most service virtualization tools on top of setting up test data capabilities will offer the possibility to define response times for the virtual services so you can create a production-like environment.

When you select a tool to use for service virtualization, keep the problem you are trying to solve in mind. Ask yourself a few questions about the problem at hand and what service virtualization can do to solve it.

Here are a few sample questions which could jumpstart the process for you:

• Are service calls to real services slowing automation efforts?
• Is lack of access to third party or backend services limiting testing efforts?
• Is using real services the best place to test new code?
• What problems might we need to address to create and maintain a virtual service for testing?

Traffic Parrot 5.6.0 released, whats new?

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

Features

• gRPC unmatched requests now display the closest match in both the logs and error response description. For example:

  UNKNOWN: Traffic Parrot Virtual Service: No responses matched the given request. See the Traffic Parrot logs for more details.
                                                 Request was not matched
                                                 =======================
  
  -----------------------------------------------------------------------------------------------------------------------
  | Closest stub                                             | Request                                                  |
  -----------------------------------------------------------------------------------------------------------------------
                                                             |
  helloworldgreetersayhello-38d8ac56-38fe-4a57-89b3-5af8368  |
  874a5.json                                                 |
                                                             |
  ANY                                                        | ANY
  helloworld.Greeter/SayHello                                | helloworld.Greeter/SayHello
                                                             |
  Protocol: GRPC                                             | Protocol: GRPC
                                                             |
  {                                                          | {                                                   <<<<< Body does not match [equalToJson]
    "inputName" : "example"                                  |   "inputName" : "not matching"
  }                                                          | }
                                                             |
  -----------------------------------------------------------------------------------------------------------------------

• Upgraded WireMock to 2.25.0
• Upgraded Proto compiler to 3.10.1

Fixes

• Fixed support for reserved fields in gRPC proto files
• Errors when compiling proto files are now reported in the logs
• Swagger/OpenAPI example dates are now considered when performing an import

Changes

• New toggle trafficparrot.virtualservice.grpc.check.mapping.schema.allow.missing.fields that can be set to true to allow gRPC mapping files to have fields missing when compared to the proto schema. This is to allow for usages where there are fields that are intentionally omitted to pick up on the default.

We also made the following changes in the 5.5.3 release:

Fixes

• Fixed support for gRPC error mappings in the new static analysis check
• Fixed support for gRPC dynamic response mappings in the new static analysis check
• Fixed support for gRPC mappings with repeated fields in the new static analysis check
• More consistent error reporting format for errors in dynamic responses, to make it clear which helper had a problem
• Always print log file in the Maven/Gradle plugin console if Traffic Parrot fails to start

Features

• New state management examples added to the examples project

How to configure a Traffic Parrot JMS IBM MQ mock via APIs to run in it in CI Jenkins

How to create REST JSON API mocks with Traffic Parrot by recording HTTP requests and responses

Traffic Parrot 5.5.1 released, whats new?

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

Features

• Traffic Parrot can now check that gRPC mapping files match proto schema on startup. You can enable this check to prevent startup if mapping files are out of date when compared to the proto schema.
  • The following property enables the feature: trafficparrot.virtualservice.grpc.check.mapping.schema.on.startup=true
  • Currently supports checking gRPC mapping equalToJson request matchers
  • Currently supports checking gRPC mapping response
  • This feature is currently in public beta and is subject to change
  • Please let us know your feedback feedback@trafficparrot.com and help us improve this feature

Changes

• Traffic Parrot now only requires a single port for the UI:
  • trafficparrot.gui.http.port=8080
  The following ports are no longer used by the UI:
  • trafficparrot.virtualservice.http.management.port=8083
  • trafficparrot.virtualservice.jms.management.port=9093
  • trafficparrot.virtualservice.http.port=8081

We also made the following fix in the 5.4.5 release:

Fixes

• gRPC mapping files will now be written with the correct status code of 0 to represent a successful response status. gRPC mapping files with status code 200 will continue to be interpreted as status code 0 to preserve backwards compatibility.

How can I expose multiple port numbers for stubs?

"How can I expose multiple port numbers for stubs, so that each downstream component has an individual port number?"

In Traffic Parrot, you have only one port per Traffic Parrot mock instance. If you would like to use separate ports, you will need to start one Traffic Parrot instance per port.

Let’s discuss the problem you are trying to solve by using multiple ports, please email us at help@trafficparrot.com

We also recommend reading "3 ways to deploy and share virtual services and API mocks"

Traffic Parrot in Software Testing News test automation directory

Thanks to Software Testing News for adding Traffic Parrot to their Test Automation directory!

What is the difference between JMS IBM MQ and Native IBM MQ?

Traffic Parrot allows mocking and service virtualization of IBM MQ via both Java JMS and IBM MQ Java APIs. What does that mean?

First, let's start with what is an API. In simple terms, an API is a specification that describes how two or more systems will communicate with each other. For example, how your application will communicate with a third party service. 

If you are using IBM MQ as your message broker, your application will use an API to put and read messages to and from the IBM MQ queues.

There are several ways your application can put and read messages to and from IBM MQ queues.

For example, if your application is written in Java, it can use the IBM MQ classes for JMS or the IBM MQ classes for Java. So, you would be using either the JMS API or the (Native) MQ Java API.

Both methods are APIs to the same Java interface to the MQI and share the majority of features. So, it should not matter which API you use for mocking and service virtualization, as they should be compatible. You should be able to swap them around with no impact in many situations. Just remember, if you use some features that are only available in IBM MQ classes for JMS, then Traffic Parrot will not be able to support them if you use Traffic Parrot Native IBM MQ.

The recommended way of doing mocking and service virtualization of IBM MQ using Traffic Parrot would be to use the same API your application is using.

If your application is using IBM MQ classes for JMS, we advise you to use Traffic Parrot JMS IBM MQ. If your application is using the IBM MQ classes for Java, then we recommend you use Traffic Parrot Native IBM MQ. If your application is using both APIs, we recommend you use those both in Traffic Parrot as well.

Mocking SOAP services

"Can we mock soap services?" - website visitor, USA.

Yes! Here is a tutorial how to do that:

Twitter @java: Testing Microservices - Overview of 12 Useful Techniques - Part 1 with Liam Williams

Thanks to @java for the recognition by Tweeting Liam's and Wojciech's article!

"The combination of a microservice architectural style and container-based infrastructure requires a testing strategy that is compatible with this brave new world. A microservice architecture relies more on over-the-wire (remote) dependencies and less on in-process components, and your testing strategy and test environments need to adapt to these changes." - Wojciech Bulaty and Liam Williams for InfoQ

Read more: https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/

Trending article: 12 useful techniques when testing microservices

Liam and Wojciech's article "Testing Microservices: Overview of 12 Useful Techniques - Part 1" is trending at position 1 on InfoQ!

"When working with microservices, you have more options because microservices are deployed typically in environments that use containers like Docker. In microservice architectures, your teams are likely to use a wider variety of testing techniques. Also, since microservices communicate more over the wire, you need to test the impact of network connections more thoroughly. Using tools and techniques that better fit the new architecture can allow for faster time to market, less cost, and less risk." - Wojciech Bulaty and Liam Williams for InfoQ.

Read more: https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/

Traffic Parrot 5.4.0 released, whats new?

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

Features

• Added JMS REST API to count the number of requests made that match the given criteria using POST /api/jms/requests/count and reset the count using DELETE /api/jms/requests
• See the OpenAPI documentation or import the Postman workspace for more information on the API usage

Fixes

• Fixed usage of {{ anyNumber }} to match numbers within JSON string fields

Testing Microservices: Overview of 12 Useful Techniques - Part 1

"The combination of a microservice architectural style and container-based infrastructure requires a testing strategy that is compatible with this brave new world. A microservice architecture relies more on over-the-wire (remote) dependencies and less on in-process components, and your testing strategy and test environments need to adapt to these changes." - Wojciech Bulaty and Liam Williams for InfoQ 15th Aug 2019.

Liam and Wojciech have just published an article about testing microservices. A big thank you to the InfoQ editorial team, who were fantastic help getting this article ready.

Read more: https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/

How multiple teams can use Traffic Parrot

“Is it possible to segregate a Traffic Parrot installation across multiple teams?” - Consultant Developer at a global software consultancy in Portugal.

It's a great question, and we hear it quite often, so we have decided it would be good to blog about it!
Start with exploring the "3 ways to deploy and share virtual services and API mocks".

If you want to use Diagram 3 deployment style which is where we recommend using Traffic Parrot, Diagram 3a below shows an example of how you could configure TP to be used by multiple teams:

Click to enlarge

On the left, you see a team responsible for the Legacy Banking Application. They used to have two environments DEV and QA that now connect to a Payment virtual service. They also have a CI build in Jenkins, and develop the application on their laptops. All of those environments use the same versioned virtual service artifact, that is used to spin up the Payment virtual service.

On the right, you can see another team in the same organisation but working in the new world of microservices. Developers and QAs are running developing and testing those microservices on their laptops, but they also have a GitLab pipeline setup. All of those laptops and the pipeline are running separate virtual services that are built from the source code and versioned in GIT source code.

Here is a sample workflow of how you can manage your API mocks as code to handle the distributed deployment and versioning of the API mock artifacts in the example above:

Click to enlarge

You can see a sample developer workflow, how to create the API mocks (virtual services), test them together with the microservice. The workflow ends in the developer checking in and pushing his changes to GIT. And then a GitLab pipeline picking up those changes and running the checks, publishing and deploying the artifacts.

Please keep in mind, these are only examples to demonstrate how our clients use Traffic Parrot, the details can differ and will be specific to every organization.

If you would like a recommendation of how to deploy the virtual services or API mocks specific to your project, please contact help@trafficparrot.com and we will be more than happy to assist you.

3 ways to deploy and share virtual services and API mocks

There are three common ways you can deploy and share your virtual services or API mocks.

The first one is where you reuse the same hardware and virtual service across many users, see Diagram 1.

What you see in Diagram 1 is an organisation that uses a DEV environment to deploy a Legacy Banking Application. That application needs to connect to, among many others, a payment service. The DEV environment is connected to a payment virtual service, that is running in a service virtualization tool deployed on a virtual machine. That same virtual service is shared with two more users (or agents if you wanna call them that). The Jenkins slave is running build jobs (pipelines) of that same Legacy Banking Application and connects to the shared Payment virtual services. We also have a QA that is testing a new microservice on her laptop, that requires connectivity to the Payment service, and she is using the same shared Payment virtual service.

The second one is where you reuse the same hardware but create a copy of virtual service per user, see Diagram 3. The three users/agents (DEV environment, Jenkins Slave and the QA) are using three copies of the same Payment virtual service, running on the same shared virtual machine.

The third option is where you use a copy of virtual service per-user, but deploy it per-use instead of using a shared environment, see Diagram 3. In this case, each user/agent uses a copy of the Payment virtual service that is for their exclusive use. So, the DEV environment is connected to a Payment virtual service running in Docker on OpenShift in the internal cloud. The Jenkins Slave is spinning up a Payment virtual services just before running the tests of the Legacy Banking Application. And, the QA is spinning up a Payment virtual services on her laptop.

Please keep in mind, these are only examples to demonstrate what our clients do, the details can differ and will be specific to every organization.

Traffic Parrot is not recommended in Diagram 1 and 2 style deployments

Firstly, if you want to do Diagram 1 or Diagram 2 shared deployment style, we recommend using other commercial service virtualization tools instead of Traffic Parrot. It is possible to use Traffic Parrot in those environments, but we do not recommend it.

Traffic Parrot is recommended in Diagram 3 style deployments

If you would like to use distributed deployment, similar to the one described in Diagram 3, we recommend using Traffic Parrot.

If you would like a recommendation of how to deploy the virtual services or API mocks specific to your project, please contact help@trafficparrot.com and we will be more than happy to assist you.

Traffic Parrot 5.3.1 released, whats new?

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

Features

• New operating system specific release with bundled JRE:
  • Any operating system with no bundled JRE: trafficparrot-no-jre-5.3.1.zip
  • 64-bit Linux with bundled JRE: trafficparrot-linux-x64-jre-5.3.1.zip
  • 64-bit Mac with bundled JRE: trafficparrot-mac-x64-jre-5.3.1.zip
  • 64-bit Windows with bundled JRE: trafficparrot-windows-x64-jre-5.3.1.zip
  • 32-bit Windows with bundled JRE: trafficparrot-windows-x86-32-jre-5.3.1.zip
• New state management REST API for global state:
  • Create or update state using PUT /api/state/global/{name}
  • Get state using GET /api/state/global/{name}
  • Reset all state using DELETE /api/state
  • See the OpenAPI documentation or import the Postman workspace for more information on the API usage
  • {{ manageState 'example' 'set' 1234 }} to set a variable in a response template
  • {{ manageState 'example' 'get' }} to get a variable in a response template

What can I do with Traffic Parrot?

"What can I do with Traffic Parrot? I am trying to simulate resource allocation scenario for fog computing. Can I simulate that using Traffic Parrot?" - a trafficparrot.com website visitor via the chat window.

Traffic Parrot is a service virtualisation and API mocking tool, which are two techniques from the test doubles family.

"Sometimes it is just plain hard to test the system under test because it depends on other components that cannot be used in the test environment. This could be because they aren't available, they will not return the results needed for the test or because executing them would have undesirable side effects. In other cases, our test strategy requires us to have more control or visibility of the internal behavior of the SUT."  - Test Double at XUnitPatterns.

For more information have a look at the tutorial: Getting started with stubbing, mocking and service virtualization.

Traffic Parrot 5.2.0 released, whats new?

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

Features

• WireMock 2.10.1 compatible REST API is now mounted on /api/http/* on the Traffic Parrot UI/API port (default 8080) for example POST /api/http/requests/count can be used to count requests
• Added gRPC REST API to count the number of requests made that match the given criteria using POST /api/grpc/requests/count and reset the count using DELETE /api/grpc/requests
• See the OpenAPI documentation or import the Postman workspace for more information.

Fixes

• Fix scenarios dropdown UI on Windows browsers

Changes

• Rename "request body" to "request message payload" in the gRPC UI

Does Traffic Parrot support HTTP/2 (HTTP2)?

Not yet directly. Currently only via gRPC.

gRPC leverages HTTP/2 underneath and benefits from many of the efficiencies of HTTP/2. Traffic Parrot supports gRPC. Traffic Parrot does not support HTTP/2 directly yet, please reach out to us to have a look at the HTTP/2 beta version.

Traffic Parrot 5.1.0 released, whats new?

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

Features

• gRPC improvements
  • Import gRPC proto files using the import button on the gRPC Add/Edit page
  • Convert OpenAPI files to gRPC proto files with openapi2proto using the import button on the gRPC Add/Edit page
  • Use the trafficparrot.virtualservice.grpc.openapi2proto.plugin.location property to configure the openapi2proto binary location, which can be either AUTO_DETECT (which searches the system environment path, go/bin directory and Traffic Parrot plugins directory) or a specific location
• Configure HTTP proxy mappings on the HTTP Add/Edit page to allow routing some calls to the virtual service and some calls to real services
• Added support for database queries in responses
  • New {{ databaseQuery }} helper
  • Configure JDBC connections in the database-connections.json file
  • Provide the JDBC driver JAR files for your database in the lib/external folder
• Added support for default value when using {{ select }} to look up values in CSV files
• Added support for the IBM®MQ Message ID as Correlation ID pattern

Fixes

• When a property is missing from trafficparrot.properties we now report which key is missing in the logs
• PDF files can now be correctly recorded and replayed as HTTP multipart/related attachments

Changes

• Removed equal to matcher from gRPC edit mapping form (equal to JSON always makes more sense to use than equal to)
• New toggle trafficparrot.virtualservice.grpc.message.field.naming to choose whether to define gRPC mappings using CAMEL_CASE field names or using the ORIGINAL field name case used in the proto files
• Binary (non plain text) HTTP responses are now recorded in .bin files

How to approach Traffic Parrot speed issues during load testing

We had one of our prospects reach out to us this week:

"I am stuck with my POC (Proof Of Concept project) on Traffic Parrot as I am facing out of memory issues at 30 TPS for 100 concurrent users for HTTP and IBM MQ JMS, please advise." -  Test Automation and Service Virtualization Consultant at an Australian Bank

Typically we advise starting by having a look at common approaches to speeding up Traffic Parrot for performance testing which is located here: https://trafficparrot.com/documentation/5.0.x/performance_testing.html

If the guidelines outlined there do not resolve the issue, please contact support@trafficparrot.com, and we will suggest how we can improve the performance of Traffic Parrot in your specific use case.

In this particular case increasing the memory from -Xmx128mb to -Xmx1g (Traffic Parrot JVM heap size increase from 128MB to 1GB) in jvm.args resolved the issue. The issue was that the request to response mappings used by the prospect were complex enough to require higher than standard use of memory for 100 concurrent users.

Traffic Parrot 5.0.0 release, whats new?

We have released Traffic Parrot 5.0.0. Here is a list of what is included in the new release:

Features

• New HTTP skeletons feature:
  • OpenAPI specifications are used to generate a list of HTTP skeletons that can be used to help design HTTP mappings in the Traffic Parrot user interface
  • Place OpenAPI specifications in the openapi configuration directory to populate the dropdown menu or use the upload button on the HTTP Add/Edit page next to the dropdown
  • This replaces the old scenarios.js dropdown, which has been removed (see changes section below for migration instructions)
• Maven plugin improvements:
  • New trafficparrot:check-environment goal to run in the pre-clean phase to check nothing is preventing a successful start of Traffic Parrot
  • Check that there is not an existing Traffic Parrot instance running
  • Check for locked files or directories that are unable to be cleaned on Windows (typically this is because a file is open in a text editor or command prompt)
  • Improved speed when cacheDownload is enabled by also caching the extracted zip file
  • Accept either file:/// or file:// syntax when specifying file URLs
  • Remember to upgrade your plugin version to 5.0.0

Fixes

• The randomInteger and randomDouble helpers now return a number type instead of a string, so that they can be combined with other helpers that require a number. For example when combined with the stringFormat helper: {{stringFormat '%02d:%02d' (randomInteger 0 59) (randomInteger 0 59)}}

Changes

• The scenarios.js HTTP dropdown has been removed.
  • We recommend migrating to an OpenAPI specification file which can be used to produce a similar dropdown via the new HTTP skeletons functionality
  • Please email help@trafficparrot.com with your scenarios.js file and we will translate it to an OpenAPI file for you
  • Removed unused property trafficparrot.gui.scenarios.resource.name
• Improved reporting of port clashes and how to change ports in trafficparrot.properties

I want to learn Service Virtualization

"I want to learn Service Virtualization for mocking. How can I do that?" - An anonymous trafficparrot.com website visitor.

We recommend looking at the Service Virtualization and API mocking tutorials available on our website, starting with Chapter 1: Getting started with stubbing, mocking and service virtualization and then Chapter 2: How to record and replay HTTP SOAP requests and responses to create API mocks.

If you would like to schedule a free 45-minute "Service Virtualization and API mocking" webinar for your company or your team, please reach out to contact@trafficparrot.com, and we will organise it at a time convenient to you and your team.

Do you have single user licenses?

Recently a website visitor asked:

"Do you have single user licenses?" - QA Lead at a Russell 3000 company, Pennsylvania.

Yes, we do support the single user scenario. For a single user, we have an option for a single floating license (only one instance allowed to be running at the same time).

If you are interested in single user licenses, we would be happy to provide a quote according to your requirements. Please contact sales@trafficparrot.com for more information.

Error 2085 when creating IBM MQ mocks

Recently we have received a query from an engineer evaluating Traffic Parrot:

"Hi! I am trying to do an MQ stub, but facing some issues. I get an error code 2085, can you please help me out?" - Software Engineer at a Bank, Australia.

Typically error 2085 means the queue or topic your application or Traffic Parrot connects to does not exist on the IBM MQ broker.

It will be hard to help more just by looking at the error code alone. If you see an error like this, please contact support@trafficparrot.com to schedule a quick call with screen sharing to resolve your issue.

P.S.
Here is a tutorial of JMS IBM MQ: https://trafficparrot.com/tutorials/mocking-or-simulating-jms-ibm-websphere-mq.html
Here is a video tutorial JMS IBM MQ: https://www.youtube.com/watch?v=mWxSuVWnv1M 
Here are the docs for JMS: https://trafficparrot.com/documentation/4.7.x/jms.html
Here is how you can run IBM MQ on Docker for development and testing purposes: https://trafficparrot.com/tutorials/How_run_a_free_Docker_IBM_MQ_for_Developers_on_Windows_Linux_and_AWS.html

Is there a free version of Traffic Parrot?

Recently we have received a query from one of our website visitors:

"Hello! Is there free version of Traffic Parrot available?" - Software Engineer at a Software Consultancy, Ukraine.

We do not offer a free version, however, we do have a 14-day trial available.

If you are interested in the enterprise edition, we would be happy to set up a call to discuss budgetary pricing according to your requirements, please contact sales@trafficparrot.com

Alternatively, you can compare the open source tools available on Wikipedia.

Service Virtualization Test Container Pattern

Traffic Parrot has first-class support for the Service Virtualization Test Container Pattern (also called API Mock Test Container or API Simulation Test Container)

Let's assume if you work with a Jenkins Continuous Integration pipeline and test your microservices there to get to production fast. The more external dependencies the build pipeline has, the more risk you have those dependencies will cause the build to be unstable and fail because of external dependency issues, not related to the code quality. External dependencies should be kept to a minimum. For example, run your database in Docker per build (on Jenkins Slave), not in a shared environment. It is a pattern similar to the "sidecar" container pattern recommended by Jenkins just used in tests.

We recommend running your API mocks in the same process as your tests (and using Service Virtualization As Code - API Mocking As Code). If you decide to run your API mocks or virtual services in a separate process though, run them in a docker container. This way you are taking your automation to the next level, you have a fully automated and reproducible build pipeline.

Because of issues with dependencies, avoid using centralized instances running API mocks and virtual services outside your build pipeline. You can use them for exposing mocks to other teams and departments and for manual exploratory testing, but not in your automated CI builds.

Running in a container like Docker also means you are doing Infrastructure as code with all of its benefits to your business.

How to run Traffic Parrot behind a firewall? How to use a proxy?

Recently one of the Traffic Parrot users asked us:

"When I try to capture traffic from a HTTP API it does not register anything or generate an error, it just does not capture anything. I have a proxy in my company, but I can not find how to tell the application to go through that proxy to make the recording. Please advise." - A developer at a Colombian bank

Are you running Traffic Parrot inside an organisation where you have to use a HTTP Proxy to access APIs?

No problem!

You can find documentation here how to use a HTTP Proxy here: https://trafficparrot.com/documentation/4.4.x/user_guide.html#outbound-http-proxy

How to add requests and responses manually

A user recently asked us this good question.

> I would like to know your inputs for below query: if we do not have any restful API details apart from one URI and one set of Request and response.

> That to URI is not accessible in our dev cloud. then we do not have any recording url for that to put on since it is not accessible. How can we do virtualization here using traffic parrot

You can add requests and responses manually to Traffic Parrot by clicking on HTTP->Add/Edit.

Delaying JMS messages in IBM MQ or Active MQ (mocking and service virtualization)

Starting from version 4.4.0 Traffic Parrot supports delayed JMS messages.

Here is the documentation how to enable delayed messages: https://trafficparrot.com/documentation/4.4.x/jms.html#edit-jms-delay

It is useful in scenarios like performance testing, when you would like to simulate a dependency system that takes a while to process messages asynchronously and its impact on your systems performance.

Tutorial: Mocking and simulating gRPC APIs

gRPC is an open source protocol used for remote procedure calls which was initially developed at Google. Traffic Parrot support gRPC service virtualization and API mocking.

If you would like to learn more have a look at the new tutorial Chapter 5: Mocking and simulating gRPC.

Tutorial: How to use Traffic Parrot APIs

Sometimes developers would like to configure Traffic Parrot programmatically. You can do that using Traffic Parrot APIs.

Have a look at the video below for more details. Here is the Postman collection that should allow you to explore what APIs are available. Here you can also find the Swagger/OpenAPI documentation of the APIs.

The European Software Testing Summit: The meaning of Agile in 2018

On the 12th of December 2018 we were invited to the The European Software Testing Summit to lead a group discussion with the audience. The topic was "The meaning of Agile in 2018".

Wojciech Bulaty, the founder of Traffic Parrot, led the discussion with the audience.

The session went well and there were many exchanges of experiences with the attendees.

Here is what we have learnt during the session:

• The difference between the Agile Manifesto, Scrum, Scaled Agile Framework and Extreme Programming can be confusing to even well established industry practitioners.
• Following Agile practices can speed up testing significantly
• At some companies, software testers do not trust developers, which results in duplicated efforts in test automation, because testers automate what already has been automated by developers 
• At some companies, the Agile Transformation is done without sufficient training resulting in unfinished transformations which are worse than not started transformations
• It is not easy to get Agile working, but the results are worth it. Faster time to market and less time spent on testing software.