Our team has a vast experience with different tools available on the market. It makes Traffic Parrot stand out form the other commercial offerings and work well in microservice-like architectures developed by decentralized, autonomous or cross-functional teams.
Designed for self-service product teams (autonomous, decentralized and cross-functional). It will allow you to avoid a centralized admin team (i.e. no Centre Of Excellence teams) that could be a bottleneck for the teams when creating API mocks and virtual services.
One simple but powerful component with a small footprint (200MB disk space, 128MB RAM) allowing you for more flexibility. Can be run on your Laptop/Desktop, CI server, Docker/Kubernetes, Cloud or VM. This allows for implementing Service Virtualization As Code (API Mocking As Code) and Service Virtualization Test Container Pattern which are the industry standards when working on microservcie architectures.
A licensing model and cost plan that fits Continuous Integration and DevOps practices.
HTTP(S), IBM MQ, gRPC, JMS, RabbitMQ, ActiveMQ, File Transfers, gRPC and other protocols
Both test and development teams
Different ways of creating virtual services like manual request/response import and record and playback.
Traffic Parrot has first-class support for the service virtualization as code pattern (also called API mocking as code).
If you have any state or configuration you manage in your IT infrastructure the best solution in most cases is to version control it in a source control system like Git. For example, if you are running on Kubernetes and Docker, your whole infrastructure might be defined in a source control repository as Dockerfiles and Terraform Kubernetes configuration files. Its called Infrastructure as code
It is advised to do the same with your API mocks and virtual services. All your mocks and virtual services should be stored in a version control system such as Git. In the case of Traffic Parrot, this is possible since all request to response mapping files are stored on the filesystem as JSON files. Alternatively, you can use the JUnit TrafficParrotRule directly in your JUnit tests. This way you are taking your automation to the next level, you have a fully automated and reproducible build pipeline.
Because of the issues that can arise with manual processes, avoid having API mocks and virtual services that are updated manually and never stored in Git or a similar source control system. Store all your API mocks and virtual services in a source control system.
The business justification (quoting Wikipedia): "Infrastructure automation enables speed through faster execution when configuring your infrastructure and aims at providing visibility to help other teams across the enterprise work quickly and more efficiently. Automation removes the risk associated with human error, like manual misconfiguration; removing this can decrease downtime and increase reliability. These outcomes and attributes help the enterprise move towards implementing a culture of DevOps".
Traffic Parrot has first-class support for the Service Virtualization Test Container Pattern.
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 as a database test container (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.
Traffic Parrot can be deployed in a decentralised as well as a centralised model. The decentralised deployment model is designed for teams working with microservice architectures.
As Martin Fowler observed, when working with microservices it is typical that "the (microservice) teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management." The full range of skills will also involve API mocking and service virtualizaiton. In such environments, every team will one or more team members that are capable of doing service virtualizaiton or API mocking on their own without having to rely on a centralised team of administrators.
For the team to be fully autonomous, they will need flexibility when and how to run their virtual services and API mocks. Traffic Parrot can be deployed on a Laptop/Desktop, CI server, Docker/Kubernetes, Cloud or VM; hence it is possible for the team to be fully autonomous by having their instances of Traffic Parrot.
Traffic Parrot HTTP(S) module is based on open source WireMock. If you use only the HTTP(S) module in Traffic Parrot, it is possible to use WireMock where possible, and Traffic Parrot only in cases where WireMock is lacking functionality. This way you get less vendor lock-in.
ThoughtWorks observed in July 2014 that "The gap between what 'enterprise-class' commercial packages provide and what is actually needed is widening. This is especially true for internet facing applications. Innovative solutions that really scale and easily support modern techniques such as continuous delivery are written by practitioners for practitioners. They originate with many internet scale companies and are refined as open source software. Big enterprise solutions often obstruct effective delivery due to their accumulated bloat, cumbersome licensing restrictions, and feature sets that are driven by check-lists and imaginary requirements far removed from the realities of most development teams.". This means there is less risk in choosing a tool that is building on top of open source technology and one that follows practices established in the open source community.
| Open source | Free | HTTP(S) | JMS | IBM® Websphere MQ | File transfers | gRPC | Raw TCP | Other protocols | Has a basic GUI | Has an advanced GUI | Scriptable/Programmable | Docker support | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Charles Proxy | No | No | Yes | No | No | No | No | No | No | Yes | Yes | No | No |
| Hoverfly | Yes | Yes | Yes | No | No | No | No | No | No | Yes | No | Yes | Yes |
| Mountebank | Yes | Yes | Yes | No | No | No | No | Yes | SMTP | No | No | Yes | Yes |
| SoapUI MockServer | Yes | Yes | Yes | No | No | No | No | No | No | Yes | Yes | No | No |
| Traffic Parrot | No[2] | No | Yes | Yes | Yes | Yes | Yes | No | Request Beta Invite[3] | Yes | Yes | Yes | Yes |
| WireMock | Yes | Yes | Yes | No | No | No | No | No | No | Yes | Yes | Yes | Yes |
| Other enterprise offerings | See below "Why do our customers choose Traffic Parrot over other enterprise offerings?" | ||||||||||||
There are many service virtualization tools available either as open source distributions, commercially available off-the-shelf software (COTS), or SaaS offerings. Our customers find it as difficult to attract and retain development talent as any firm operating in today's competitive environment and choose to pay for Traffic Parrot to get guaranteed support and avoid spending internal development time and energy on what would essentially be re-inventing the wheel. They focus their talents on additions to their core offering that increase the value to their end customers.
Get a free 45-minute service virtualization and API mocking webinar for your team, tailored to your goals and challenges. Leave your email address below and we will contact you shortly to schedule it:
Mountebank is a great tool, we recommend it on many occasions. If you currently use Mountebank:
or your development and testing team would benefit from a UI on top of the programmable interface
need full support for:
WireMock is a great tool, we recommend it on many occasions. Traffic Parrot HTTP(S) component is build on top of WireMock.
One tool that fits many protocols. Traffic Parrot supports not only HTTP(s) but also asynchronous messaging with JMS (ActiveMQ TCP, ActiveMQ AMQP 1.0, Azure AMQP 1.0, RabbitMQ AMQP 0.9.1, IBM® WebSphere MQ 7.5+), Native IBM® WebSphere MQ 7.5+, File transfers over a filesystem and gRPC and more
Full SOAP and REST JSON support More
Comprehensive dynamic responsesMore
Man in the middle HTTPS Proxy. More
Designed for manual exploratory testing, automated performance testing and functional testing of large and legacy systems More
Have many additional extensions available as well things like Passthrough Mode, Recording filtering by content type, and many more.
No more testers left behind! More
Traffic Parrot is designed for both testers and developers.
Majority of open source service virtualization software (like WireMock) is written by developers for developers. It is great for developers, but testers get left behind. The way we are different to most open source is that our tool is designed with both developers and testers in mind. We have programmable APIs for developers and an intuitive user interface for testers to use. We provide first class support to both testers and developers. We value collaboration and make sharing virtual services between developers and testers easy, which can be costly to implement just with open source.
Often developers are implementing the new best practices and using the cutting edge technology, following the latest trends. Then, often testers get left behind, and have to keep up with developers. Our tool helps to facilitate the communication between development and testing. Find out more in the Continuous Delivery team video.
How long can you wait for a bug fix? In open source projects fixing issues might last weeks, months or years. More
We aim to fix them in a few days to a week. Even if you fix an issue in an open source project codebase yourself and create a pull request, it might take a few weeks to a few months before the new version is released. We aim to release new versions in a few days to a week.
Service virtualization, API testing and automation roadmap reviews and consulting More
Service Virtualization roadmap review
Performance testing roadmap review
API testing roadmap review
Test automation roadmap review
Service virtualization, API testing and automation training More
Free 45-minute session "Introduction to service virtualization" for your team
4-hour “SV in manual API testing” workshop
4-hour “SV in automated API testing” workshop
4-hour “SV in performance testing” workshop
Charles Proxy is a great tool. There are significant differences between Traffic Parrot and Charles Proxy, though.
Traffic Parrot supports multiple protocols, not only HTTP(s) but also JMS and IBM® Websphere MQ, File transfers and gRPC
Traffic Parrot is scriptable and programmable. It is a complete service virtualization and API mocking platform with many extensions available.
Traffic Parrot can be run anywhere. On your laptop, on a server, in docker, on a Jenkins/Bamboo/CircleCi/TeamCity agent and on AWS. You can run Traffic Parrot on a server using command line (headless). The GUI is accessed via a web browser.
Our tool is designed for manual exploratory testing, automated performance testing and functional testing of large and legacy systems. Its not only a HTTP Proxy aimed at debugging.
Mockito is a great tool, even we use it internally at Traffic Parrot for in-process mocks. It might not be possible to use Mockito in some situations though.
Black-box application/microservice testing (both functional and performance)
You need a graphical user interface, like a Web UI
You have too many APIs and endpoints to mock to start with and need to do a record/replay to manage the complexity short term
You want to use the same tool and testing approach for developers and testers
Provide external development and testing teams with stubs of your systems
Simulating protocol and network errors/failures
REST, JMS and MQ APIs that require visibility on protocol level, not in Mocktio mocks only
Logging communication sequence diagrams in acceptance tests