This topic 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:

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. Select the test suite’s Test Case Explorer node, then choose Create Virtual Asset from the shortcut menu.

  4. In the wizard that opens, modify the virtual asset file name and location if desired, then click Next.
  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 con-figure 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 (i.e., have SOAtest automatically discover the changing parameters and con-figure 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.

  6. Click the Finish button.

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.