Service Virtualization with Parasoft Virtualize 9.9.5

Software testing is an important aspect of the software application development cycle. Service virtualization plays a big role in software testing as it provides the user with the ability to test the application under various possible events which can be expected from the backend service. If the actual backend used by application is not ready to be integrated for testing that is one possible case where a virtualized service will be useful. One other important use of a virtualized service is imitating backend service failures and tests the application’s robustness under those failures. For example if we need to test whether our application will fail when the backend service is not available or not, a virtual asset can mimic a backend time out situation and this can be used to test our software.

1. Creating a Virtual Asset

Once Parasoft Virtualize is installed and license is activated, the first thing we need to do is creating a Virtual Asset (ask Virtual Service).  For that go to Virtual Assets -> Add New -> Virtual Asset .pva File

This will create a new Virtual Asset (referred as VA from here) in the workspace with a Responder Suite. Responder suite is the container where we are going to create one or more virtual responses to be returned to the client application.  In order to add a response we need to create a ‘Responder’.

        2. Adding a Responder to VA with URL Parameter Correlation

There are many type of Responders can be created from Parafost Virtualize. Some of the common examples are XML or JSON responders, Literal responders etc.  It is possible to add more than once responder to VA, and correlate it with an incoming http header, url parameter, request body element etc.  As the first steps let’s add a XML responder.  An XML responder will return an xml message when it is called. For this follow Responder Suite -> New tool -> Plain XML Responder. Then add a XML message to response body.

Now let’s correlate this XML responder to a url parameter which is coming from client application, so when the Virtual Asset is called client needs to pass that specific url parameter in the address if it needs to have XML responder in return. For that go to HTTP URL Parameters and select ‘enable correlation’. Then give a parameter name to correlate.

In order to get this XML response the client will call below address.

http://[virtual_server_host:port]/My_firstVA?response=1

         3. Adding a Responder to VA with HTTP Header based Correlation

If we need to return some response from VA based on the value of an incoming HTTP header, that can be done using header correlation. Let’s add the JSON Responder this time. Add a JSON response.

Then go to ‘Responder Correlation’ and add a header name (e.g. RESPONSE_JSON=true) and value which we need to correlate with. Then select ‘Enable Correlation’

             4. Change default HTTP_SC return status of the Responder

Assume that we need to test when a backend service fails and return HTTP Status as 500. It is not possible to break the real backend service for us to get 500 from it. So we can create a virtual responder which returns 500 and test our application using that. For this create the Response as explained in above, and go to Options -> Return Status. By default responder is configured to return HTTP 200 OK. Unclick that and then we can add whichever HTTP_SC code and message that needs to be returned with the Responder.

             5. Adding a delay to the Message Responder ( Modeling a backend timeout scenario)

A Responder in VA can be configured with a response time delay which can be used to test a backend timeout situation. First point the client application endpoint to the VA’s address. Then we can create a Responder and wait for certain amount of time before sending that response. For e.g if the endpoint timeout is 5 seconds, then give the Responder delay as 10 seconds. So when the VA is called it will wait for 10 seconds before send the response back to client application. By this time client’s endpoint will have timed out after 5 seconds.

           6. Hosting the VA in a Server

Now let’s test this Virtual service. By default the VA is already added to the local server. The ‘Servers’ pane in Parasoft Virtualize displays the existing servers list. You can add any remote servers to this too. 

          7. Testing the Virtual Service

I am using Chrome PostMan extension as the test client.  The URL of the service would be, http://localhost:9080/My_First_Virtual_Asset 

As there are many responders, I am going to test one response with a url parameter. Below is the full request/response in POSTMAN.

http://localhost:9080/My_First_Virtual_Asset?response=1

Debugging Apache ODE Test Classes with Maven Surefire Plugin

There are some occasions when we need to debug the test classes in our unit tests base in the maven project. Ever wondered how to do that??  Well i did at the beginning when i had to debug the ODE test cases and that was when i found the way with maven surefire plugin. However this method can be used with any maven built project than ODE too.

Environment: Ubuntu 10.04 

                       Apache ODE 1.3.5 

                       Apache Maven 2.2.1 

                       Maven Surefire Plugin 2.5 

                       IntelliJ Idea 10.0.3

Here we go. Apache ODE's root 'pom.xml' file generally includes the maven surefire plugin by default as a test framework. The surefire 'debug' option is used to remotely debug the test classes in any of the modules in ODE project which is built using maven. First of all let's create a remote debug configuration with 'localhost' and default '5005' port, which is used by surefire. I have called mine as 'maven'.

Figure 1: Create a remote debug for Surefire

Now go to the specific module in ODE project directory in which we want to debug the test class. If you need to debug a single test class simply use the following command.

odeTrunk/bpel-compiler$ mvn clean install -Dmaven.surefire.debug -Dtest="CompilationMessageTest" -o

-Dmaven.surefire.debug : This tells maven to enable the surefire debug property and it will listen on default port 5005, for a remote debug connection to get attached.

-Dtest="CompilationMessageTest" : This command is used to declare the exact test class we need to debug. 

-o : Informs maven to build the module offline. If you need to build it online just remove the '-o' command.

When maven starts to build in debug mode we can see that it will hang on the console when waiting for a remote debug configuration as shown here.

Figure 2: Starting debug a single test class

At this time start the 'maven' debug in the IDE and it will pause at the given breakpoint in our 'CompilationMessageTest' class in the 'bpel-compiler'module.

Figure 3: Remote debug the test class

We don't have to declare a specific test class name under -Dtest command to debug that single test. Instead we can enable debugging for all the test classes and keep the breakpoint in the necessary class as our wish. In this case maven will run all the test classes in that module and will break at the specified breakpoint when it come to the relevant test class. The command for this should be;

odeTrunk/axis2-war$ mvn clean install -Dmaven.surefire.debug -o