Virtualize multiple behaviors in parallel with Rational Test Virtualization Server

Use two variants of a virtual service for different systems under test

This article helps users of IBM Rational Test Virtualization Server to configure their test environment to have multiple variants of a stub running simultaneously. These variants make it possible to run multiple test cases in parallel where there are multiple instances of the system under test available. Variants also make it possible for two components of a composite system to receive different responses from the same service interface.

The problem

Why would you want to run two different variants of a virtual service simultaneously? Typically, this function is used when there are two different systems under test (SUTs), or two components of an integrated system, both of which depend on the same service interface definition. It is possible that your situation requires those two components to receive different responses from that service interface, even if they submit identical requests. This can occur in two main situations:

  • Multiple test cases are being run in parallel: For example, when the SUT is hosted in a cloud, it is easy to deploy multiple identical instances on which to run the separate test cases. These multiple test cases might require different behaviors of the virtual service for the service interface in question.
  • Multiple components in a SUT: These components depend on the same service interface, but, for purposes of the test case, must receive different responses. The virtual service design cannot distinguish between these components based on the requests alone.

This article considers the case of multiple test cases being run on separate SUTs in parallel. However, the same steps and principles apply to separate components; just replace the phrase SUT with component.


The example

This article follows a particular service virtualization example, as shown in Figure 1. In this example, the system under test is a web application. This web application has a dependency on the calculator web service, which is provided by IBM® Rational® Test Control Panel in IBM® Rational® Test Virtualization Server.

Figure 1. The test environment without service virtualization
A diagram showing the tests, SUT and dependency

As shown in Figure 2, you set up virtualization of this dependency for use when testing the web application that depends on it.

Figure 2. The test environment with service virtualization
The dependency has been replaced with a virtual service

It is possible to deploy multiple instances of this web application, which is especially useful when testing, so that not all tests are waiting to use the same instance. In this example, we will set up virtualization in two test cells so that the testing can be performed concurrently, with two tests being run at any one time – one on each test cell.

The calculator dependency is not hosted within the production environment of the web application being tested, but it is an external dependency. Therefore, it is also not hosted within the test cells themselves, but both cells, by default, point to the same external dependency, as shown in Figure 3.

Figure 3. Multiple instances without service virtualization use the same dependency
Both systems point to the same dependency

As shown in Figure 4, you virtualize the dependency to provide control of the service and its behavior in the scope of an individual test cell.

Figure 4. Multiple instances with service virtualization use separate virtual services
Each system has its own virtual service

Intended audience

The intended audience of this article are users with some initial experience in using IBM® Rational® Integration Tester and Rational Test Virtualization Server. It is aimed at users who are faced with a problem of running different systems against different virtual service variants, or users who want to learn more about how to use Rational Test Control Panel environments and the Rational Integration Tester HTTP proxy.


Prerequisites

Ensure that you have access to the following software:

  • Rational Test Control Panel, which is available in the Rational Test Virtualization Server installer.
  • A virtual service, already created, in a Rational Integration Tester project, which must already have an environment defined. In the examples, this article uses a project into which is imported the calculator WSDL file from the Rational Test Control Panel examples, which can be found on a local install at http://localhost:7819/RTCP/examples/.
  • An HTTP proxy from the IBM Rational Integration Tester Platform Pack
  • IBM Rational Integration Tester Agent running and registered with Rational Test Control Panel.

Overview of virtual service variants

This scenario, as described in the problem statement, includes a virtual service that behaves in two different ways for different callers at any one time. This article refers to these as different variants of the stub. However, this is not a term found in the Rational Integration Tester user interface.

How you use these variants depends on your situation. For example, they might need to return different data, use different test data sets, or one might need to simulate an error and one might need to simulate a success case. You define the variants using one of the following options:

  • Create a parameterized stub: The single stub takes an input value into one of its tags in the tag data store. Configure the stub to behave differently based on that input value. For example, if the virtual service returns a number, such as a credit score, and the only difference between the two variants is what number it returns, you can configure it to take the number to return as an input tag. See the documentation for Rational Integration Tester for more information on stub input tags.
  • Create a single stub for the first variant and modify for others: You can create a single stub for the first variant, and publish that at one version (for example, version 1.0). Then modify it to behave as the other variant and publish it as a second version (for example, 2.0). This approach is not recommended, unless one of the systems under test really is intended to run against a particular baseline of the virtual service. This approach is not suitable for modeling different versions of the service interface or of the real implementation of the service. In those cases use a parameterized stub.

Environments to bind logical to physical

In Rational Integration Tester, an environment is used to bind the logical model of the system to physical resources, such as web servers or message brokers. The logical model does not contain enough information about the physical resource (for example, the host and port of a web server) to make a request to an operation or to virtualize an operation.

For example, you might have an environment for the bindings used for each of the following: the production environment, the staging environment, and a continuous integration environment. Both the systems under test and the dependencies might have different bindings in each of these environments. These might be different physical test cells, or they might be logical groupings of shared components.

Rational Test Control Panel extends this concept, and can confine its intercepts (including the HTTP proxy) and agents to the scope of a particular environment. It is good practice to use a different HTTP proxy for each of your environments to prevent them from interfering with each other's traffic. For example, you do not want a virtual service in the continuous integration testing environment to route traffic from the staging environment.

Bindings for virtualized service

The calculator web service being virtualized is external to the system under test, and so all systems under test will be using the same HTTP endpoint for it, on the same DNS domain name. Therefore, the bindings to physical resources in the Rational Integration Tester project are the same for both environments.

Environments are created in Rational Test Control Panel when you publish the virtual services to it. Environments in the control panel are grouped into domains. In this article the domain used is called default, but this can be any name. You can create a domain when you publish virtual services or using the Administration page in the control panel.

For the scenario in this article, you need two environments: one for each of the systems under test. That is, each of the variants of the virtual service must be run in its own environment.


Create an environment in Rational Integration Tester

This article assumes that you have created an initial environment when you modeled your system. For example, when importing a WSDL file, it creates an environment for you with the correct bindings. In this example, the original environment is named TestCell1.

In your Rational Integration Tester project, create a second environment, as shown in Figure 5:

  1. Click Project > Edit environments
  2. Select your existing environment.
  3. Click Clone the selected environment.
  4. Give the new environment a name (for example, TestCell2).
Figure 5. Cloning an environment
A screen capture of the clone environment button

Configure the HTTP proxies

As stated above, Rational Test Control Panel can scope its HTTP proxies to individual environments. This scope is defined in the HTTP proxy configuration file. It is possible to run two instances – that is, two HTTP proxies – from a single installation of the Rational Integration Tester Platform Pack.

Set up two instances of the platform pack's HTTP proxy -- one for each of your environments:

  1. If the HTTP proxy is running, stop it.
  2. Inside the installation directory of the platform pack, duplicate the httptcp directory, and name the new copy httptcp2.
  3. Edit the httptcp/registration.xml file: uncomment the <domains> element at the bottom of the file, and insert the name of your first environment and its domain. This will mean this proxy only picks up rules for that environment. For example, if your domain is called default and your first environment is called TestCell1, the code looks similar to Listing 1.
Listing 1. Configure the first proxy with the TestCell1 environment
<!-- A proxy does not need to register against a domain or environment.
     By default it will proxy for all domains/environments. If you want to restrict
     its use then add <domain> entries based on the example below. Each domain
     may have 0 or more environments →
    <domains>
        <domain name="default">
            <environment name="TestCell1" />
        </domain>
    </domains>

Note: If you have not yet created a domain, choose its name now. When the proxy registers, it will create the domain for you.

  1. Edit the file httptcp2/registration.xml:
    1. Change the <http-proxy> element's port attribute to be a different value, e.g. 3130.
    2. Delete the <https-proxy> element (or change its port number and plainCommsPort number to different values).
    3. Comment out or delete the <forward> element.
    4. Uncomment the <domains> element at the bottom of the file, and insert the name of your second environment and its domain. For example, if your domain is called default, and your second environment is called TestCell2, the code looks similar to Listing 2.
Listing 2. Configure the second proxy with the environment TestCell2
<!-- A proxy does not need to register against a domain or environment.
     By default it will proxy for all domains/environments. If you want to restrict
     its use then add <domain> entries based on the example below. Each domain
     may have 0 or more environments →
    <domains>
        <domain name="default">
            <environment name="TestCell2" />
        </domain>
    </domains>
  1. Start both of these proxies, by running httptcp/startup.bat and httptcp2/startup.bat.
  2. Go to the agents page of the Rational Test Control Panel and select the appropriate domain. Make sure you can see both HTTP proxies registered, each reporting a different environment. You may need to refresh the page if the domain was just created.
Figure 6. The registered proxies
The agents page showing the registered proxies

Click to see larger image

Figure 6. The registered proxies

The agents page showing the registered proxies

Configure systems under test to use the different environments

Viewing the domain on the agents page

In addition to HTTP proxy entries, other entries are displayed on the Rational Test Control Panel, as shown in Figure 6. Each HTTP proxy also registers a TCP entry, because it allows TCP port forwarding. One of the proxies may not state a second port, because the <https-proxy> element is deleted (in the previous Step 4) to avoid port conflicts. The RTVS entry is the Rational Integration Tester Agent.

For a SUT to use an environment, two pieces of configuration are needed:

  • The SUT must be configured with the same bindings that are used in the Rational Integration Tester project's environment. No action is required to make this happen at this stage, because the environment in Rational Integration Tester should have been created using the values that the SUT is using, for example, by importing the WSDL describing the services it uses.
  • The SUT must be configured to send its HTTP traffic through the HTTP proxy for the appropriate environment.

Configure each of your systems under test to use the appropriate proxy, which will determine which environment's virtual services are used by that system:

  • The systems that are to go to the first variant of the stub should be configured to use the first proxy (on default port 3128).
  • The systems that are to go to the second variant of the stub should be configured to use the second proxy, using the port you configured in the <http-proxy> element of httptcp2/registration.xml (3130 in the previous examples).

Create and publish the virtual service variants

  1. Create the two variants of your virtual service using one of the strategies described in the overview of virtual service variants. How to create virtual service stubs is outside the scope of this article. For more information, see the Rational Integration Tester information center and the links in the resources section.
  2. Publish stubs to Rational Test Control Panel under both environments. This action makes both variants available to Rational Test Virtualization Server.
    1. Go to the test factory perspective.
    2. Right-click on the Logical folder and then click Publish stubs.
    3. As shown in Figure 7, type a new version number (for example, 2.0).
    4. If no domains exist on Rational Test Control Panel, select Create new domain, enter a name, and click OK.
    5. Select your domain and both environments.
    6. Click Publish.
Figure 7. Publishing stubs
A screen capture of selecting both environments

Start the two variants of the virtual service

Now, whenever one of the variants of the virtual service is required by a test in one of the test cells, that variant can be started in the appropriate environment. It will then only affect traffic for that test cell, and will not interfere with testing in the other test cell.

To demonstrate this, start each variant of the stub in the appropriate environment.

  1. Go to Rational Test Control Panel, open the VIE page, and select the first environment, as shown in Figure 8.
Figure 8. Selecting an environment
Screen capture of the environment selection screen

Click to see larger image

Figure 8. Selecting an environment

Screen capture of the environment selection screen
  1. Start the first variant.
    • If you created a single stub to accept an input parameter, in the start stub dialog select Configuration > Input tags, and in the value input field for the appropriate input tag enter the value for the first variant.
    • If you created two versions of a single stub, one for each variant, after you select the stub's name, select the first version.
  2. Return to the VIE page and select the second environment. Start the second stub.
    • If you created a single stub to accept an input parameter, in the start stub dialog select Configuration > Input tags, then in the value input field for the appropriate input tag, type the value for the second variant.
    • If you created two versions of a single stub, one for each variant, select the stub's name and select the second version.

Now the system under test that is configured to use the first proxy will receive responses from the first variant of the stub when it submits a request to the virtualized service interface, and the system that is configured to use the second proxy will receive responses from the second variant of the stub.


Why this works

This method works because each of the variants of the virtual service creates a routing rule for the proxies that are registered against the environment in which that virtual service is running. To see the rules that exist, go to the Agents page of Rational Test Control Panel, select the appropriate domain, and click Show rules.

  • The proxy registered against the first environment picks up the routing rule created by the first virtual service, and so directs traffic to that service.
  • The proxy registered against the second environment picks up the routing rule created by the second virtual service, and so directs traffic to that service.

Because you configured each system under test to use a different proxy, they each use a different virtual service, even though both are running at the same time and have the same rule condition by which they match requests.

Environments can be used in Rational Integration Tester and Rational Test Control Panel in two main ways, and there is significant overlap between the two:

  • Rational Integration Tester can assign different physical transports – that is, different endpoint bindings – to a service in different environments. This article does not use this feature. Both environments use the same binding, because in both cases, the systems under test have the same endpoints configured for the dependency that is being virtualized.
  • In Rational Test Control Panel, the different environments can be used to represent different test labs, or different collections of machines being used for testing. In this article, each test lab (whether real physical test labs, or a conceptual separation of testing resources) has its own HTTP proxy, so that the traffic in each case can be controlled separately without interfering with testing that is happening in the test lab represented by the other environment. In the same way, Rational Test Virtualization Server agents can be registered against a single environment, so each test lab can have its own agent or collection of agents, again to avoid interference between environments.

Conclusion

This article begins with two different systems under test that use two different variants of a virtual service simultaneously. To achieve this, the example runs each system under test against a different environment, where each environment has its own HTTP proxy, and each virtual service is run in the appropriate environment. This article offers help for how to use environments in Rational Integration Tester and Rational Test Virtualization Server to achieve more flexible, powerful, parallel testing and virtualization.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into DevOps on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • DevOps digest

    Updates on continuous delivery of software-driven innovation.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • IBM evaluation software

    Evaluate IBM software and solutions, and transform challenges into opportunities.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=DevOps, Rational
ArticleID=966502
ArticleTitle=Virtualize multiple behaviors in parallel with Rational Test Virtualization Server
publish-date=03252014