Virtualizing HTTP
You can simulate an HTTP connection with a virtual service, also known as a stub.
Procedure
- In the Architecture School perspective, create a logical HTTP connection resource (Creating logical HTTP connections) and a physical web server resource for HTTP (Creating physical web server resources). If you are not creating the stub by using the Recording Studio perspective, also create an operation that uses the HTTP connection. See Options for creating test resources.
- Create virtual services (message-based stubs) to represent
these resources. See Creating message-based stubs.
- To create stubs by using the Recording Studio, see Recording HTTP and HTTPS traffic and Stub creation by using the Recording Studio.
- To virtualize REST APIs that use path parameters (web URL schemas) manually, see Virtualizing a REST API without recording or synchronization.
- You can run stubs directly in HCL OneTest™ API, or publish them to HCL Quality Server and run them there. See Publishing and running stubs.
- Use one of the following methods to configure the system
under test so that it sends messages to the stub.If you recorded HTTP messages in the process of creating the stub, notice that these choices are similar. Differences between recording and virtualizing include the fact that packet capture does not allow virtualization, and no direct connection option is available for recording.No proxy, no virtualization shows a network with no virtualization.
- The simplest method is to configure the system under test to send its HTTP traffic through the
HCL OneTest™ API
HTTP proxy server (HTTP proxy, no virtualization-HTTP proxy forwards to other system). When the stub is running, the
messages are dynamically routed to the stub. When the stub is not running, the messages are sent to
the live system, if available. Using the proxy also enables sift and pass-through for HTTP stubs.
For more information about configuring systems under test to use the HTTP proxy, see HTTP/TCP proxy setup.HTTP proxy, no virtualization shows the system under test addressing a request to the live system, but the HTTP client is configured to make all its connections to the HTTP proxy. No stub is running, so the request is forwarded to the live system.In HTTP proxy with virtualization, the stub is running, so the request is forwarded to the stub. Depending on the configuration of the stub or the configuration of the proxy, the proxy might take one the following steps:
- Forward all traffic for the requested host to the stub
- Filter the traffic based on other parts of the message, such as the path of the URL or the HTTP header values
If the system under test specifies a host other than the live system, the traffic does not match the rules that the stub has set up in the proxy. The traffic is, therefore, forwarded to the specified "other" system, as shown in HTTP proxy forwards to other system. You can see those rules on the Network Dashboard in HCL Quality Server. For more information, see Viewing running agents. - If the system under test cannot be configured to use an HTTP proxy,
then the next alternative is to configure the HTTP proxy as a reverse
proxy. Change the host name and port of the endpoint that is used
by the system under test, such that the system sends traffic to the
host and the port that is specified in the bind attribute of the forwarding
rule for the proxy. The reverse proxy has many of the benefits of
using the standard proxy, including dynamic message routing and sift
and pass-through. However, it does not work if the responses from
the stub contain absolute URLs that the system under test then dereferences.
In those circumstances, the standard proxy is required. See Configuring a HTTP(S) reverse proxy or TCP port forwarding.Reverse proxy shows a reverse proxy.
- Another alternative is to configure the system under test to connect
directly to the stub (see Direct connection to
stub). This process
requires assigning a fixed port number to the transport that the stub
uses. To do so, take one of the following actions:
- Go the Logical view of the HCL OneTest™ API Architecture School perspective, right-click the HTTP connection resource, and click Open physical resource.
- Go the Physical view of the Architecture School perspective and double-click the web server resource.
- The server where HCL OneTest™ API is running
- If running through HCL Quality Server, the server where the HCL OneTest™ API Agent is running
For more information about socket overrides, see Creating physical web server resources.
Next, configure the system under test to use as its endpoint the host and port number of the server where the stub will run, rather than using the host and port for the live system. Be aware of the following limitations:- As with the reverse proxy, this method does not work if the responses from the stub contain absolute URLs.
- This method does not route messages dynamically. When the stub is not running, connections fail (see Direct connection to stub that is not running).
- All traffic for the specified endpoint is routed to the stub. This method does not filter the traffic based on operations.
- If the stub is running, it can perform pass-through to the live system, with the following limitation. If the operation stub settings define that paths, method or headers are filtered, then the path, method, and headers in the request must match the filter. If they do not match, the stub is not invoked, an error response is returned to the client, and pass-through does not occur. If the stub is not running, then connections fail.
- With other methods, you can have multiple Agents and the stub can run on any Agent that is registered with HCL Quality Server for the correct environment. With this method, if running through HCL Quality Server, you must configure the system under test to use the exact machine on which the Agent runs the stub.
- The simplest method is to configure the system under test to send its HTTP traffic through the
HCL OneTest™ API
HTTP proxy server (HTTP proxy, no virtualization-HTTP proxy forwards to other system). When the stub is running, the
messages are dynamically routed to the stub. When the stub is not running, the messages are sent to
the live system, if available. Using the proxy also enables sift and pass-through for HTTP stubs.
For more information about configuring systems under test to use the HTTP proxy, see HTTP/TCP proxy setup.