Service virtualization with Parasoft Virtualize Community Edition

This post was published on February 22, 2017

A couple of years ago, I took my first steps in the world of service virtualization when I took on a project where I developed stubs (virtual assets) to speed up the testing efforts and to enable automated testing for a telecommunications service provider. The tool that was used there was Parasoft Virtualize. I had been working with the Parasoft tool set before that project, most notably with SOAtest, their functional testing solution, but never with Virtualize.

In that project, we were able to massively decrease the time needed to create test data and run tests against the system. The time required to set up a test case went down from weeks to minutes, literally, enabling the test team to test more and more often and to introduce end-to-end test automation as part of their testing efforts. That’s where my love for the service virtualization (SV) field began, pretty much.

After that, I did a couple more projects using Virtualize, and started building more experience with SV, exploring other solutions including open source ones like SpectoLabs Hoverfly or WireMock. What I quickly learned, also from my conversations with the people at Parasoft, was that a lot of organizations see the benefits (and even the need) for service virtualization. However, these organizations often get cold feet when they see the investment required to obtain a license for a commercial SV solution, which easily runs into the tens of thousands of dollars. Instead, they:

  • turn to open source solutions, a perfect choice when these offer all the features you need, or
  • start to build something themselves, which turns out to be a success much less often.

The people at Parasoft have clearly taken notice, because last week saw the official announcement of the free Community Edition of the Virtualize platform. Virtualize CE is their answer to the rise in popularity and possibilities that free or open source solutions offer. In this post, we’ll take a first look at what Virtualize CE has to offer. And that is quite a lot.

Features
Here are a couple of the most important features that Virtualize CE offers:

  • Support for HTTP and HTTPS
  • Support for literal, XML and JSON requests and responses and SOAP-based and RESTful API simulation
  • Ability to create data driven responders (more on that later)
  • Recording traffic by acting as a proxy and replaying the recorded traffic for quick and easy virtual asset creation

Of course, there are also limitations when compared to the paid version of Virtualize, some of which are:

  • Traffic is limited to 11.000 hits per day
  • No support for protocols such as JMS and MQ, nor for other traffic types such as SQL queries or EDI messages
  • No ability to run Virtualize through the command line interface or configure virtual asset behaviour through the Virtualize API
  • Support is limited to the online resources

Still, Virtualize CE has a lot to offer. Let’s take a look.

Downloading and installation
You can download Virtualize CE from the Virtualize product page, all it takes is supplying an active email address where the download link will be sent to. It’s quite a big download at 1.1 GB, but this has a reason: it includes the full version of both Virtualize and SOAtest (the Parasoft functional testing solution). This means that when you decide to upgrade to the full version, all you need is another license. No reinstalling of software required. After downloading and installing the software, you can simply unlock the CE license through the Preferences menu by entering the email address you supplied to get a download link. That’s it.

Creating a first virtual asset
As an example, I’m going to create a simulation of a simple API that returns data related to music. Virtualize either lets you create a virtual asset from scratch or generates a skeleton for it based on an API definition in, for example, WSDL, RAML or Swagger format. For this example, I’ve taken this RAML definition of a simple music management API. I won’t talk you through all the clicks and keystrokes it takes to create such an asset, but trust me, it is very straightforward and takes less than a minute. After the virtual asset skeleton has been created, you see the virtual asset definition with responders for all supported operations:

Our virtual asset with all of its responders

Even better, it is automatically deployed onto the Tomcat server running within Virtualize, meaning that our virtual asset can be accessed right away (after the Tomcat server is started, obviously). By default, the server is running on localhost at port 9080, which means that we can for example do a GET call to http://localhost:9080/Jukebox/songs (which returns a list of all songs known to the API) and see the following response:

Our first response from a Virtualize responder

This response is defined in the responder responsible for answering to the GET call to that endpoint, in the form of a predefined, canned response:

The definition of the above response

To alter the response, you can simply change the text, save your changes and the updated virtual asset will automatically be deployed to the Tomcat server.

Making the virtual asset data driven
That’s all well and good, but it gets better: we can make our virtual asset a lot more powerful by creating the responses it returns in a data driven manner. Basically, this means that response messages can be populated with contents from a data source, such as a CSV or an Excel file or even a database table (accessed via JDBC). As an example, I’ve created an internal Table data source containing songs from one of my favourite albums of the last couple of years:

Data source definition

Based on the song ID, I’d like the virtual asset to look up the corresponding record in the data source and then populate the response with the other values in that same record. This is a mechanism referred to as data source correlation in Virtualize. It is defined on the responder level, so let’s apply it to the GET responder for the http://localhost:9080/Jukebox/songs/{songId} endpoint:

Configuring data source correlation

What we define here is that whenever a GET request comes in that matches the http://localhost:9080/Jukebox/songs/{songId} endpoint, Virtualize should look up the value of the path parameter with index 2, which is {songId}, in the songId column of the Songs data source. If there’s a match, the response can be populated with other values in the same data source row. The mapping between response message fields and data source columns can be easily defined in the response configuration window:

Populating the responder message with data source values

But does it work? Let’s find out by calling http://localhost:9080/Jukebox/songs/d155b058-f51f-11e6-bc64-92361f002676 and see if the data corresponding to the track Strong (not coincidentally my favourite track of the album) is returned.

Response returned by the data driven responder

And it is! This means our data driven responder works as intended. In this way, you can easily create flexible and powerful virtual assets.

One last feature I’d like to highlight is the ability to track requests and responses. With a single click of the mouse, you can turn on Event Monitoring for individual virtual assets and see what messages are received and sent by it in the Event Details perspective, for example for logging or virtual asset debugging purposes (remember that your virtual assets need to be tested too!):

The Virtualize Event Viewer shows requests and responses

Apart from the features presented here, there’s much, much more you can do with Parasoft Virtualize CE. If you find yourself looking for a service virtualization solution that’s easy to set up and use, this is one you should definitely check out. I’d love to hear your thoughts and experiences! And as always, I’ll happily answer any questions you might have.

"