Virtualizing TCP

You can simulate a TCP connection with a virtual service, also known as a stub.

About this task

The following instructions apply to general-purpose TCP transports. Although some TCP-based transports have their own logical and physical transport types, the general steps are the same.

Procedure

  1. In the Architecture School perspective, create a logical TCP connection resource (Creating logical TCP connections) and a physical TCP server resource Creating physical TCP servers. See Options for creating test resources.
  2. Create virtual services (message-based stubs) to represent these resources. See Creating and modifying message-based stubs. To create stubs by using the Recording Studio, see Recording TCP traffic.
  3. 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.
  4. Use one of the following methods to configure the system under test so that it sends messages to the stub.
    If you recorded TCP 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.
    Figure 1. No proxy, no virtualization
    The client application is connected directly to the live system.
    • The simplest method is to configure the HCL OneTest HTTP/TCP Proxy, as a reverse TCP proxy (see Proxy server changes the destination host to the live server and Proxy server changes the destination host to the stub). Change the hostname 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. 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. See Configuring a HTTP(S) reverse proxy or TCP port forwarding.
      Proxy server changes the destination host to the live server shows the system under test addressing a message to the host system where the proxy server is running. In the absence of a running stub, the proxy server then re-addresses the message to the live system, as specified in the bind attribute of the forwarding rule for the proxy.
      Figure 2. Proxy server changes the destination host to the live server
      The proxy changes the destination host to that for the live system.
      Note: Many TCP applications make a single permanent connection to the live system and send multiple messages across it. Ensure that your stub is started before the application connects to the TCP proxy. Failure to do so will result in the application making a connection to the live system and the stub will not be used.
      Proxy server changes the destination host to the stub again shows the system under test sending a message to the proxy host. This time a stub is running, so the proxy server reroutes the message to the stub, based on the rule that the stub created on the proxy. You can see those rules on the Network Dashboard in HCL® Quality Server. For more information, see Viewing running agents.
      Figure 3. Proxy server changes the destination host to the stub
      The proxy changes the destination host to that for the stub.
    • 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, go the Physical view of the HCL OneTest™ API Architecture School perspective, right-click the TCP server resource, and click Open physical resource. On the Server page, Socket Overrides section, enter a number for the Port field that does not conflict with anything on the host where the stub will run. That host is one of the following servers:
      • 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 TCP servers.

      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:
      • This method does not route messages dynamically. When the stub is not running, connections fail.
      • All traffic for the specified endpoint is routed to the stub. This method does not filter the traffic based on operations.
      • 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 you use HCL® Quality Server, you must configure the system under test to use the exact machine on which the Agent runs the stub.
      Direct connection to stub shows a direct connection from the system under test to the system that hosts the stub. No messages go to the live system; they are all addressed and sent directly to the stub. To filter the messages, use the proxy server described earlier.
      Figure 4. Direct connection to stub
      Direct connection to the stub ignores the live system
      Direct connection to stub that is not running shows that the connection fails if the stub is not running, because the client connects directly to the port where it expects the stub to be running. To avoid this problem, use the proxy server described earlier.
      Figure 5. Direct connection to stub that is not running
      The direct connection fails if the stub is not running

Results

The dependency for the system under test is now virtualized. Traffic that matches the operations that are specified in the stub (or all traffic, in the case of direct connection to the stub) now receives virtualized responses instead of connecting to the live system.