Service virtualization and API mocking tools for microservices

These tools are also called API simulation, API mocking, API mocks, over the wire test double and stubs. They are the next generation of tools [1] that allow for testing you components in isolation and support Continuous Delivery, Continuous Integration, DevOps and Agile as first-class citizens. They are designed for decentralized, autonomous, cross-functional or product teams.
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 Partial[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 No No Yes Yes
Other enterprise offerings See below "Why do our customers choose Traffic Parrot over other enterprise offerings?"
[1] We are comparing here only the next generation service virtualization tools, and not including the early generation ones.
[2] Traffic Parrot HTTP(S) component is built on top of open source WireMock. Keep in mind that Traffic Parrot supports more use cases than WireMock such as more extensions for dynamic responses and proxying HTTPS traffic via a HTTP proxy (HTTPS tunneling).
[3] FIX, FAST, FIXatdl, SWIFT, AMQP, MQTT, RabbitMQ, SonicMQ, CORBA, FTP, SFTP, .NET WCF, RMI, MTP, TIBCO EMS, CICS, SAP RFC, JDBC, Mongo, Databases, OFX, IFX, RIXML, Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS), AWS IoT Message Broker, XMPP, Google Cloud Messaging (GCM), Azure Event Grid, Azure Event Hubs, Azure Service Bus, STOMP, Thrift and Avro. Other features and protocols available on request.

Why do our customers choose Traffic Parrot over other enterprise offerings?

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.

Unlike other solutions we are

  • Designed for autonomous, decentralized, cross-functional or product teams. It will allow you to avoid a centralized admin team that could be a bottleneck for the teams when creating API mocks and virtual services.

  • One simple but powerful component with a small footprint (less than 50MB of disk space) 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 Sidecar Service Virtualization Pattern which are the industry standards when working on microservcie architectures.

  • A licensing model and cost plan that fits Continuous Integration and DevOps practices.

Download trial

Similar to other enterprise commercial solutions we also support

  • HTTP(S), JMS/MQ, 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.

Download trial

What Traffic Parrot does not yet support

  • A visual interface where you could customize more complex workflows. Instead, you write custom plugins/extensions yourself in Java or ask us to write custom plugins/extensions for you.

Small footprint

It can be run on your Desktop/Laptop, VM, Docker/Kubernetes and the cloud.

Run in CI

You can run Traffic Parrot in Jenkins, TeamCity, Bamboo, and CircleCi. You do it by configuring it via a Maven plugin or using REST APIs.

Service Virtualization As Code (API Mocking As Code)

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".

Service Virtualization As Code (API Mocking As Code)

Sidecar Service Virtualization Pattern (Sidecar API Mocks Pattern)

Traffic Parrot has first-class support for the sidecar Sidecar Service Virtualization Pattern (Sidecar API Mocks 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 (on Jenkins Slave), not in a shared environment. It is a pattern similar to the "sidecar" container pattern recommended by Jenkins.

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.


Decentralised deployment designed for microservice architectures

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.


Partial open source with lower level of vendor lock-in

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.


Should you build your tools in-house?

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.

How is Traffic Parrot different to WireMock?

WireMock is a great tool, we recommend it on many occasions. Traffic Parrot HTTP(S) component is build on top of WireMock.

If you currently use WireMock:
  1. but need JMS, IBM® Websphere MQ, file transfers, gRPC or other protocol support
  2. or your dev and test team would benefit from a UI on top of the programmable interface
  3. or need full support for SOAP, REST JSON or comprehensive dynamic responses
let’s schedule a 20 minute call to explore if Traffic Parrot is a better fit for your needs.

Multiple protocols

  • One tool that fits many protocols. Traffic Parrot supports not only HTTP(s) but also asynchronous messaging with JMS, IBM® Websphere MQ, File transfers and gRPC

  • Full SOAP and REST JSON support More

    1. matchesXML matcher that allows for SOAP request matching
    2. matchesJSON matcher that allows for REST JSON request matching
    3. A visual XML editor
  • Comprehensive dynamic responsesMore

    We allow you to generate dynamic responses based on data fromn the SOAP or REST JSON requests. Have a look at the SOAP example video.
  • Man in the middle HTTPS Proxy. More

    While testing mobile applications you might want to define a HTTP proxy in Android or iOS Genymotion simulator or your real device. When your application connects to the backend systems via HTTPS Traffic Parrot will act as a man in the middle HTTPS proxy without your application even noticing that it is being ticked. WireMock supports only HTTP, not HTTPS.

Designed for QA use-cases

  • Designed for manual exploratory testing, automated performance testing and functional testing of large and legacy systems More

    1. Graphical User Interface, ideal for quick and easy manual exploratory testing.
    2. Predefined extensions (dynamic responses, pass-through mode, use request data in responses, record only specified content types, etc.) for advanced service virtualization of large-scale or legacy systems.
    3. Define mappings from templates to for easier and faster exploratory testing
    4. Easy management for HTTPS certificates.
    5. Importing traffic from production servers (via Splunk, tcpdump, log files) for performance testing (on request)
    6. We listen to our customers and add new features on a weekly basis.
  • 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.

Support, Consulting and Training

  • 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

    1. Service Virtualization roadmap review

    2. Performance testing roadmap review

    3. API testing roadmap review

    4. Test automation roadmap review

  • Service virtualization, API testing and automation training More

    1. Free 45-minute session "Introduction to service virtualization" for your team

    2. 4-hour “SV in manual API testing” workshop

    3. 4-hour “SV in automated API testing” workshop

    4. 4-hour “SV in performance testing” workshop

How is Traffic Parrot different to Charles Proxy?

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.

How is Traffic Parrot different to Mockito?

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.

Examples where it is not possible to use Mockito and you could consider Traffic Parrot

  • 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

Examples where Mockito might not be the best option and Traffic Parrot could work better

  • 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

List of all service virtualization tools available on the market

Copyright © 2015- Traffic Parrot http://blog.trafficparrot.com
Name Url Year founded Technology Protocols
NetRecorder https://github.com/chrisyoung/netrecorder 2009 Ruby HTTP
WebFixtures https://github.com/trydionel/web_fixtures 2010 Ruby HTTP
mimic https://github.com/acoulton/mimic 2011 PHP (kohanaframework) HTTP
Clojure VCR https://github.com/ifesdjeen/vcr-clj 2012 Clojure HTTP
Ephemeral Response https://github.com/sandro/ephemeral_response 2010 Ruby HTTP
Stale Fish https://github.com/jsmestad/stale_fish 2009 Ruby HTTP
VuGenLocalReplay http://www.myloadtest.com/tools/vugen-local-replay/ 2013 PHP HTTP
mocktail https://github.com/vashishthask/mocktail 2011 Java HTTP, TCP
VCR.js https://github.com/elcuervo/vcr.js 2012 Javascript HTTP
Mocky http://www.mocky.io/ 2013 Scala HTTP
Mockey https://github.com/clafonta/Mockey 2009 Java HTTP
Node Replay https://github.com/assaf/node-replay 2011 CoffieScript (Node.js) HTTP
VCR https://relishapp.com/vcr/vcr/docs 2010 Ruby HTTP
mitmproxy https://mitmproxy.org/doc/features/serverreplay.html 2010 Python HTTP
httreplay https://davepeck.org/2013/07/22/httreplay-a-python-http-recording-library/ 2013 Python HTTP
mahimahi http://mahimahi.mit.edu/ 2013 C++ HTTP
PHP-VCR http://php-vcr.github.io/ 2013 PHP HTTP
BetaMax https://github.com/betamaxteam/betamax 2011 Java HTTP
Nock https://github.com/pgte/nock 2011 Javascript (Node.js) HTTP
NSURLConnectionVCR https://bitbucket.org/martijnthe/nsurlconnectionvcr 2012 Objective-C HTTP
REST assured https://github.com/BBC/REST-assured 2011 Ruby HTTP
mountebank http://www.mbtest.org/docs/api/proxies 2014 Javascript (Node.js) HTTP, TCP
SoapUI http://www.soapui.org/HTTP-Recording/recording.html 2005 Java Swing Application HTTP
Ready! API http://smartbear.com/product/ready-api/overview/ 2014 Java HTTP
VAPI https://vapi.ca.com/vapi 2014 SaaS HTTP
Waitrest https://github.com/bodar/waitrest 2011 Java HTTP
TestComplete

http://smartbear.com/product/testcomplete/

2014 Java HTTP
grunt-connect-prism https://github.com/seglo/grunt-connect-prism 2014 Javascript HTTP
IBM Rational Test Virtualization Server http://www-03.ibm.com/software/products/pl/rtvs unknown Unknown Many protocols are supported
TrafficParrot https://trafficparrot.com 2014 Java
Public Trial Download: HTTP(S), JMS, MQ, File transfers, gRPC

Request Beta Invite: FIX, FAST, FIXatdl, SWIFT, AMQP, MQTT, RabbitMQ, SonicMQ, CORBA, FTP, SFTP, .NET WCF, RMI, MTP, TIBCO EMS, CICS, SAP RFC, JDBC, Mongo, Databases

Request other protocols and features you need
CA Service Virtualization (CA LISA®) http://www.ca.com/us/devcenter/ca-service-virtualization.aspx 1999 Java Many protocols are supported
HP SERVICE VIRTUALIZATION http://www8.hp.com/us/en/software-solutions/service-virtualization/ unknown Unknown unknown
Stub-O-Matic https://github.com/robinj/stubo-app 2015 Python Java HTTP
Sandbox https://getsandbox.com/ 2014 Javascript HTTP
Wilma https://github.com/epam/Wilma 2013 Java HTTP
Parasoft Virtualize http://www.parasoft.com/product/parasoft-service-virtualization/ unknown Unknown Many protocols are supported
Tricentis Tosca Testsuite http://www.tricentis.com/tricentis-tosca-testsuite/ 2007 Unknown unknown
Mockable https://www.mockable.io/ 2013 Unknown HTTP
MockServer http://www.mock-server.com/ 2013 Java HTTP
api-mock https://github.com/localmed/api-mock 2014 Coffee Script HTTP
apiary https://apiary.io/pricing 2012 Ruby HTTP
Rest Driver https://github.com/rest-driver/rest-driver 2010 HTTP
WireMock http://wiremock.org/ 2011 Java HTTP
Web Service Mocker https://sourceforge.net/projects/easymocker/ 2011
Hoverfly http://hoverfly.io/ 2015
Mirage https://github.com/rusenask/mirage 2015
stubby4j https://github.com/azagniotov/stubby4j 2012 HTTP
Nagual https://github.com/emanuil/nagual 2016 HTTP
Puffing Billy https://github.com/oesmith/puffing-billy 2012 Ruby + Rspec
Net HTTP Spy https://github.com/martinbtt/net-http-spy 2009 Ruby HTTP
Yakbak https://github.com/flickr/yakbak 2016 HTTP
VHS https://github.com/diegoeche/vhs 2012 HTTP