Home
Tester Guide
This guide describes the tasks that you can perform for testing various domains, technologies, and applications. To enable testing, you must configure and enable the environment for testing.
Tester Guide - Service Virtualization
This guide describes the tasks that you can perform for using virtual services or stubs to simulate parts of an environment if the real services are not yet available or because they are difficult or expensive to use. This guide is intended for API Testers.
Modifying message-based stubs
You can use either the Test Editor or the Stub Editor to create, modify, and enhance any legacy or new stubs created by HCL OneTest™ API.
Sift-and-pass-through capability
You can filter the messages that a stub receives, separating traffic from client and server applications that need to use the live system as opposed to a virtual system.

Tester Guide
This guide describes the tasks that you can perform for testing various domains, technologies, and applications. To enable testing, you must configure and enable the environment for testing.
- Tester Guide - API Testing
  This guide describes the tasks that you can perform for testing various domains, technologies, and applications. To enable testing, you must configure and enable the environment for testing. This guide is intended for API testers.
- Tester Guide - Service Virtualization
  This guide describes the tasks that you can perform for using virtual services or stubs to simulate parts of an environment if the real services are not yet available or because they are difficult or expensive to use. This guide is intended for API Testers.
  - HCL OneTest™ Virtualization overview
    HCL OneTest™ Virtualization is software that is used for creating, maintaining, publishing, and running message-based stubs and database stubs.
  - Virtualizing HTTP
    You can simulate an HTTP connection with a virtual service, also known as a stub.
  - Virtualizing HTTPS
    You can simulate an HTTPS connection with a virtual service, also known as a stub.
  - Virtualizing TCP
    You can simulate a TCP connection with a virtual service, also known as a stub.
  - Virtualizing a REST API without recording or synchronization
    You can virtualize REST APIs by using the Recording Studio, or by synchronizing WADL, Swagger, or RAML documents. When none of these options is available, you can still manually virtualize REST APIs that use path parameters.
  - Creating message-based stubs
    In HCL OneTest™ API, there are several methods that you can use to create a message-based stub.
  - Modifying message-based stubs
    You can use either the Test Editor or the Stub Editor to create, modify, and enhance any legacy or new stubs created by HCL OneTest™ API.
    - The Events tab
      With the Events tab, you can define how the stub will handle internally and/or externally received events.
    - The Behavior tab
      With the Behavior tab, you can add reusable behavioral entities, that is, pre-programmed intelligence, to your stub.
    - The Properties tab
      With the Properties tab, you can set up states for your stub and input parameters that can determine how the stub behaves when it runs.
    - The Performance tab
      With the Performance tab, you can change the performance characteristics of the stub either by adding delays when a stub runs or by disabling performance optimization.
    - The Session tab
      With the Session tab, you can configure the sharing of the tag data store between workers (instances of the stub), so that messages can be processed based on information that was captured from previously processed messages.
    - The Logging tab
      With the Logging tab, you can define how much information is recorded when the stub is run.
    - The Documentation tab
    - Adding a timer behavior to a stub
      You can use a timer behavior to set a timer event in a stub. After a set time period, the timer event is triggered, the stub receives the event, which it can then respond to. For example, you might have a stub to manage user sessions and you want to add a timer behavior that automatically logs out a user after 30 seconds of inactivity.
    - Example: Adding a repeating timer behavior to a stub
      In this example, you add a repeating timer event to a stub that starts after zero seconds and then repeats every 10 seconds.
    - Sift-and-pass-through capability
      You can filter the messages that a stub receives, separating traffic from client and server applications that need to use the live system as opposed to a virtual system.
      - Configuring transports
        The sift-and-pass-through capability is provided by HCL OneTest™ API to filter the messages that a stub receives, separating traffic from client and server applications that need to use the live system as opposed to a virtual system.
      - Adding business logic
        You can add logic to a stub to determine whether and how it should respond to a received request.
      - Configuring stub pass-through behavior
        You can configure a stub to use pass-through actions in HCL OneTest™ API in three ways.
    - Performance profiles
      You can use a performance profile to store response time characteristics for a stub over a period of time.
  - Creating and modifying database stubs
    You can create and modify database stubs in HCL OneTest™ API.
  - Configuring stubs to connect to HCL® Quality Server and the HTTP proxy
    A stub running on its own may not be sufficient in some cases, because it might have dependencies on services such as HCL® Quality Server or the HTTP proxy. If the stub is running on the public cloud and the services are running in the enterprise, you must configure the stub to connect to these services.
  - Publishing and running stubs
    You can publish stubs that are created in HCL OneTest™ API to HCL® Quality Server, Dockerfile and build context, Kubernetes, or Istio, if the stub is based on a supported transport.
  - Viewing results in HCL® Quality Server
    You can use HCL® Quality Server to display the results of tests that you run in both HCL OneTest™ API and HCL Quality Server.
  - Viewing usage statistics of virtual services in HCL® Quality Server
    HCL® Quality Server collects and stores usage metric data. The metric data might include the number and types of actions that are used, the features that are used in the workbench, details about Operating System or languages set while running, and so forth. You cannot view the metric data on the HCL Quality Server user interface, but it is available from the underlying implementation. Storage is either managed by H2 or optionally Apache Cassandra.
  - Viewing reports in HCL OneTest™ Server
    All the project stakeholders can view test reports for multiple testing products from the Results page on HCL OneTest™ Server. You can access the Results page from a web browser. Therefore, there is no need to install the desktop client.
  - Troubleshooting: HCL OneTest™ Virtualization
    You can use workarounds to common problems that you might encounter when you use HCL OneTest™ Virtualization.

Sift-and-pass-through capability

You can filter the messages that a stub receives, separating traffic from client and server applications that need to use the live system as opposed to a virtual system.

In HCL OneTest™ API:

Traffic from HTTP, IBM® WebSphere® MQ, CICS® , IMS™, Java™ , MQ telemetry or WebMethods Integration Server transports can be routed to a stub by examining data in the traffic on an exact matching basis.
Logic can be added to a stub to enable it to determine whether it should respond to a received request (sifting) or, when possible, send the traffic for onward processing to the real system (pass-through).
Note: Currently, this sift-and-pass-through capability cannot be used with other transports supported by HCL OneTest™ API.
Any HTTP header filters associated with the operation are applied before messages are passed to the sift-and-pass-through capability. For more information, see Filtering header values.
Note: When using a stub in sift-and-pass-through mode, only the new messages are processed. Existing messages on the queue are not processed.

Consider the scenarios illustrated in the following diagram. Stubs sift and pass-through scenario

Stubs sift and pass-through scenario

Route 1 (green): The client application sends traffic addressed to the live system. The intercept technology decides not to intercept the traffic, so it continues to the live system. If the message type is request/response, then the live system sends a response (not shown on diagram).
Route 2a (solid blue): The client application sends traffic addressed to the live system. The intercept technology decides to intercept it and sends it to the stub. The stub is either not performing sift and pass-through, or it examines the message and accepts it. If the message type is request/response, then the stub sends a response (not shown on diagram).
Route 2b (solid blue & dashed blue): The client application sends traffic addressed to the live system. The intercept technology decides to intercept it and sends it to the stub. The stub is performing sift and pass-through, examines the traffic and rejects it, passing it back to the intercept technology, which passes it on to the live system. If the message type is request/response, then the live system sends a response (not shown on diagram).

The following topics describe how to use the sift-and-pass-through capability.