The SOAP VirtResponse test step listens for a SOAP request and returns a pre-configured response before moving on. The incoming request can be validated just as the response of a SOAP request test step with the same configurable assertions.
When the execution of a test case reaches the SOAP VirtResponse test step, the test run pauses and waits for a request to the specified resource on the configured port with the specified path. Once a request is received, SOAP VirtResponse returns the result, and the test runner goes to the next step in the test case.
Such temporary virtual services can catch requests sent by webhooks. This way, you can quickly set up a temporary service to catch a single request, or make this a part of the test without setting up an application or a separate virtual API to handle the request.
You can add a SOAP VirtResponse test step as a usual test step.
– or –
You can use the SOAP response as a template. See SOAP Requests.
When you create a SOAP VirtResponse test step, ReadyAPI shows you a dialog where you can customize the test step.
 |
The dialog contains the following options:
Name – The name of the created step.
Operation – Specifies which operation the test step will mock.
Interface – Specifies which interface the test step will mock. When you change the selected interface, the list of available operations may update, as well.
Create Response – Select to create a default VirtResponse message from the schema.
Port – Specifies the port to listen on.
Path – Specifies the path to listen on.
After you set the desired values, click OK to create the test step. ReadyAPI opens its editor.
You can modify settings of the test step in its editor:
 |
The SOAP VirtResponse test step editor is similar to the usual ReadyAPI request editor.
Here is a brief description of available panels in the response editor:
Name | Description |
|---|---|
Displays the response body in the XML format. You can use this tab to specify the request body in the XML format. NoteYou can use Property Expansions to specify parameter values here. | |
Displays the header and body of the response in the text format. NoteReadyAPI populates this tab after the test step sends a response. | |
Displays the response body content as a tree. You can change elements’ and attributes’ values in-place. Just double-click the cell with the needed value. | |
Lets you specify parameter values using various fields and editors. | |
Use this panel to specify the authorization type (Basic, NTLM, or SPNEGO/Kerberos) and authorization parameters for your response. | |
Headers | Use this panel to create and modify custom header fields. |
Specify the files to attach to the response in this panel. See also SOAP Attachments. | |
Contains web service addressing settings. For information on these settings, see the Web Service Addressing specification. | |
Displays the document schema for the element that is currently selected in the XML or Outline editor. | |
Displays description for the node selected in the Outline or XML editor. The panel loads the description from the document schema if possible. | |
Provides information about response parameters used and covered by assertions during the test run. | |
Script | The context script variable available in the VirtResponse scripts, acts as both |
Once the test step receives a request, it will be available in the request editor.
The Query/Match panel allows you to specify a query that will be used to select which incoming request to handle. For example, if you specify in the XPath Query panel an expression that selects the ID, the Matching Value will contain a property expansion that returns the required ID.
Besides the test step editor, you can adjust test step behavior by using its properties in the VirtResponse Properties and Custom SOAP VirtResponse Test Step Properties panels in the Navigator.
VirtResponse Properties
Name | Description |
|---|---|
Name | The test step’s name. |
Description | Text description of the test step. |
Message Size | Shows the size of the response in bytes. |
Encoding | Specifies the encoding of the response data in the request header: |
Outgoing WSS | Specifies the outgoing WS-S configuration that will be applied to the response. |
Enable MTOM | Enables the MTOM packaging method for attachments. |
Strip Whitespaces | Removes comments and extra whitespaces from elements and attributes. Required by some servers. Works only for the request content in the XML format. |
Remove Empty Content | Remove empty elements from the request. Works only for the request content in the XML format. |
Timeout | Specifies a timeout for the test step in milliseconds. If no request has been received within the specified time, the test step will fail. If this property is 0, the timeout is ignored. |
Start Step | Specifies a test step from which the SOAP VirtResponse starts waiting for a request. It can be useful when you use a request and VirtResponse in the same test case. If you do not specify this property, the test step starts listening when the SOAP VirtResponse step is executed. |
Port | Specifies the port that the test step is listening on. ImportantThis port number is used for HTTP requests only. For HTTPS requests, it must differ from the value in the Preferences > SSL setting. See below. |
Path | Specifies the path that the test step is listening on. |
Host | Specifies the host that the test step is listening on. |
Custom TestComplete Test Step Properties
Values on the Custom TestComplete Test Step Properties tab are available to other test steps in your project. For instance, you can verify these property values with the Assertion test step, or check them and change the execution flow with the Conditional GoTo test step. To learn more, see About Properties.
This tab contains the following properties that provide access to the request and response data:
Name | Description |
|---|---|
Response | The response data is without headers. You can see the same content in the response XML panel. Property expansions are represented as they are without converting to expected values. |
Request | Data of the request without headers. You can see the same content in the request XML panel. |
In the test step toolbar, you can input the path and port to listen on during the execution.
You can add and manage assertions in the same way as for the SOAP Request test step editor.
To add, change or modify them, use the Assertion panel. You can use the following assertions:
Name | Description |
|---|---|
Property Content: | |
Verifies that the request contains the specified string. | |
Verifies that the request message contains expected contents. | |
Verifies that the request does not contain the specified string. | |
Checks whether the result of the specified XPath expression is equal to the specified value. | |
Verifies that the result of the specified XQuery expression is equal to the specified value. | |
Compliance, Status and Standards | |
Checks whether the request contains the expected value of an HTTP header. | |
Verifies that the request contains the specified HTTP header. | |
Checks whether the request is compliant with the specified schema definition. | |
Checks whether the received request is a valid SOAP request. | |
Validates that the last received request contains valid WS-A headers. | |
Validates that the last received request contains valid WS-S headers. | |
Script | |
Executes a script to perform a custom assertion. | |
While the test step editor is open, brief information on sent requests is listed in the Request Log tab. If the test step is run as part of a test case, you can see a more detailed log in the Transaction Log panel.
If you want to use the SOAP Request test step to send a request to the SOAP VirtResponse test step, place the two test steps in different test cases. Otherwise, test execution will pause on the SOAP VirtResponse test step and will never reach the SOAP Request test step.
You can use Property Expansion with SOAP VirtResponse test steps just as with SOAP requests, that is, properties can be transferred from incoming requests and to outgoing responses.
Although running a load test containing SOAP VirtResponse steps will work, these steps are not designed for load testing, and may cause significant overhead. In load tests, you can create a virtual service for your SOAP service by using virtualization.
Below, you can find information on common tasks that you can perform with the SOAP VirtResponse test step.
To configure the VirtResponse test step to listen for HTTPS requests:
Open the SOAP Request test step that will simulate an HTTPS request and check the port number there.
Open the Preferences > SSL options.
Modify the settings:
Select the Enable virtual service SSL check box.
Edit the Virtual service port setting.
This port must –
Be the same as the port you specified in the SOAP Request properties, and
Differ from the port that is specified in the VirtResponse test step properties (see below).
Specify the Virtual service KeyStore and Virtual service password properties.
Save the changes.
Open your SOAP VirtResponse test step for editing and change its Port property. Set any port that is available on your computer and is different from the port you specified in the Preferences > SSL settings.
Important
When VirtResponse is waiting for an HTTPS request, it does not check the Port property value. It listens on the host and path specified by the test step’s properties and uses the port number specified in the Preferences > SSL settings.
After you have a created SOAP VirtResponse test step, you can quickly change which Operation it virtualizes a response for.
To change the operation in a SOAP VirtResponse test step:
Open a test case that contains the needed SOAP VirtResponse test step and select it.
Select Step > Set VirtOperation from the main menu.
– or –
Right-click the test step and select Set VirtOperation.
The dialog lets you change the operation for the SOAP VirtResponse test step:
