Home
Test Author Guide
This guide describes how to create test scripts in HCL OneTest™ Performance and enhances tests by applying different test elements such as dataset, variables, and verification points. This guide is intended for testers.
Simulating services with stubs
Service stubs enable you to simulate the behavior of an actual service for a wide variety testing or integration purposes.
Editing a service stub
Service stubs are generated with a single default response for each operation in the WSDL specification. You can edit the service stub to change the default responses or to add conditional responses that can simulate the actual service.

Test Author Guide
This guide describes how to create test scripts in HCL OneTest™ Performance and enhances tests by applying different test elements such as dataset, variables, and verification points. This guide is intended for testers.
- Creating tests
  To create a test, you record representative interactions with an application.
- Editing tests
  After you record a test, you can edit it to include datasets (to provide variable data rather than the data that you recorded), verification points (to confirm that the test runs as expected), and data correlation (to ensure that returned data is appropriate for the corresponding request). You can also add protocol-specific elements to a test. When you edit a test, the modified items appear in italic type. The italic type changes to regular type after you save the test.
- Compound tests
  You can create compound tests to help you organize smaller tests into scenarios that can then be run end-to-end. You can combine tests from different extensions to achieve end-to-end flow.
- Simulating services with stubs
  Service stubs enable you to simulate the behavior of an actual service for a wide variety testing or integration purposes.
  - Service stub overview
    Service stubs are simulations of an actual service, which can be used to functionally replace the service in a test environment. A stub server replaces the actual application server.
  - Creating a service stub
    You can use a WSDL (Web Service Description Language) specification file to generate a service stub that can simulate the behavior of the original service and uses the exact same interface.
  - Editing a service stub
    Service stubs are generated with a single default response for each operation in the WSDL specification. You can edit the service stub to change the default responses or to add conditional responses that can simulate the actual service.
  - Deploying service stubs
    You deploy and run service stubs on a stub server, which is a small application server dedicated to running service stubs. The client application, or test, addresses the stub server instead of the actual application of the original service.
  - Recording service stub activity in a log file
    With service stub logging, you can monitor the interactions between an application and the stub server. When the option is enabled, one log file is created for each deployed stub. The log files are presented as a formatted HTML report.
  - Setting log level for service stubs
    While recording a service test, you can set the level of the log details that you want to collect for debugging purposes.
- Sending service requests with the generic service client
  The generic service client enables you to send requests to services for which you do not have a convenient client and to view the responses returned by the service.
- Emulating workloads
  You emulate a workload by creating a schedule and adding user groups/rate runner groups, tests, and other elements to it.

Editing a service stub

Service stubs are generated with a single default response for each operation in the WSDL specification. You can edit the service stub to change the default responses or to add conditional responses that can simulate the actual service.

Procedure

To edit the behavior of a service stub:

In the test navigator, double-click the stub to open the stub editor.
Each operation simulated by the stub is represented by an operation element, which contains Case elements that describe a condition. Each case contains a response element. Case elements are similar to test verification points and use the same presentation.
To change the default response of an operation:
1. Expand the operation and the Case : Default element, and then select the response element.
  The Case : Default element describes the response of the service stub when no other case condition is met.
2. Edit the Message content to specify the XML content returned by the service stub.
To add a conditional response case:
1. Right-click the operation and select Add > Equals Case, Contains Case, or Query Case.
  These conditional case types are similar to the Equals, Contain and Query verification points in service tests.
  - Use Equal Case to specify a response that is returned by the stub when the entire incoming message content fully matches the specified message content.
  - Use Contains Case to specify a response that is returned by the service stub when a portion of the incoming message content matches the specified message content.
  - Use Query Case to specify a response that is returned by the service stub when an XPath query meets the specified criteria.
  You can add as many case elements as necessary to simulate the behavior of the original service. Use the Up and Down buttons to change the order in which the case conditions are evaluated. Only the first matching condition is executed.
  The default case cannot be removed and is always the last case element in the operation.
2. Select the response element and edit the Message content to specify the XML content returned by the service stub. Use the Form, Tree, and Source views to change the XML content display mode.
Select File > Save or click the Save toolbar button.

What to do next

When you have finished editing the service stub, you can deploy the stub to a stub server.