This section explains how to convert your REST and SOA functional test suites into virtual assets that emulate the behavior SOAtest observed as the tests executed. 

About Virtual Assets

You can use SOAtest to model a scenario that you want emulated (you simply interact with the actual components to be emulated), then automatically "flip" that scenario into a "virtual asset" that emulates that scenario. These virtual assets can then be deployed on Parasoft Virtualize, enabling 24/7 access to components that might otherwise be unavailable or difficult to access for testing.

For example, assume you are interacting with Amazon Web Services (AWS). In order to emulate the services you are working with, you can model a scenario that interacts with the actual services, then automatically “flip” that scenario into an emulated version. With the emulated version deployed locally, you gain control over its behavior for your testing environment (instead of relying on Amazon). This way, you can easily emulate error conditions, realistic delays, and so forth.

You can create virtual assets for:

• SOAP Client tests that use JMS or MQ.
• Messaging Client tests.
• REST Client tests.

Creating Virtual Assets

To create virtual assets from a SOAtest test scenario:

1. Design a functional test suite that represents the traffic that you want the virtual asset to emulate. For instance, you can create a test suite based on historical request/reply sets from traffic, or you can design a functional test suite that sets up a sequence of events representing the contextual application behavior you want emulated.
2. Run the test suite from which that you want to create virtual assets.
3. Right-click the test suite’s Test Case Explorer node and choose Create Virtual Asset.
   
4. In the wizard that opens, modify the virtual asset file name and location if desired, then click Next.
   • You might want to save it in the "VirtualAssets" project in your team’s Parasoft Virtualize workspace.
     

5. (Optional) Specify how you want Virtualize to determine which request message parameters should be considered in determining which response the virtual asset should send. In the Message Responder tool configuration (in Parasoft Virtualize), you will be able to review and configure the response that the virtual asset should return when a message matching one of these "relevant" values is received.

   Response messages or requests do not have to be XML. However, if you want to do request/response correlation (that is, have SOAtest automatically discover the changing parameters and configure the XPaths for multiple responses) the request needs to be XML. If the request is not XML, then the virtual asset will be configured with a single response. If there is more than one test that uses JMS, the first test with a JMS configuration will be used to configure the JMS for the virtual asset.

   • Choose Automatic if you want SOAtest to automatically select the parameters that vary from request to request. With this option, all requests within the current group of similar requests (the current operation) will be mutually compared and analyzed in order to identify the parameters (element value and attribute values) that vary between those requests, then the first varying parameter discovered will be used for correlation purposes. If you know that more than one parameter can vary and more than one should be used to correlate the requests with responses, then choose the Select Relevant Parameters mode.
   • If you have a complex service and/or want to manually specify which parameters are relevant—or if there is more than one parameter to select for that determination—choose Select Relevant Parameters, then use the available controls to indicate which parameters you want to use.
     • For example, you may want to customize the parameter usage in this way if you want SOAtest to ignore things like timestamps and random session IDs when determining which virtual asset response to send.

     • Assume that the request message has three parameters: x, y, z. If you want Virtualize to consider the values of y and z in determining what response the virtual asset should send, you would specify y and z here.  The selection of y and z would then be reflected in the generated Message Responder tool’s Response settings. This is where you would specify what responses you want the virtual asset to return.
       

       When creating virtual assets from a REST client, the varying URL parameter values that were recorded when running the test will be used to establish the request/response correlations. The wizard will show similar options for selecting the relevant URL parameters.

6. Click Finish.

SOAtest automatically creates a virtual asset based on the selected test scenario. Virtual assets are implemented as a set of Message Responder tools, and are grouped in a .pva file with the specified name and in the specified location.  The resulting .pva file of Message Responder tools is added to the specified location.
You can customize the virtual assets with different request/response use cases, error conditions, delays, and so forth as described in the Parasoft Virtualize User Guide.