DevOps Test Virtualization overview
HCL DevOps Test Virtualization (Test Virtualization) is software that is used for creating, maintaining, publishing, and running message-based stubs and database stubs.
Stubs are used to simulate services within an environment for the purposes of software development and testing. Simulating parts of an environment can often be necessary if the real services are not yet available or because they are difficult or expensive to use.
Additionally, from a testing point of view, a tester will often require simple or deterministic responses from services used by the system under test (SUT) and the only way to ensure this is to develop stubs that act in a known way.
Test Virtualization offers extremely powerful tools to quickly create and manage stubs in large environments. However, stubs do not simulate underlying messaging transports. For example, although Test Virtualization does not simulate WebSphere® MQ, it can simulate a service that is accessed over WebSphere® MQ and any related stubs will still be accessed by means of WebSphere® MQ.
Test Virtualization helps developers by enabling them to create stubs representing services that are needed for the completion of development and testing but which that may not yet exist or which are difficult and time consuming to set up.
Test Virtualization helps testers by enabling them to stub out the dependencies of an SUT and to control the external dependencies of that SUT, so they can plan, organize, manage, and control their software testing more effectively and more efficiently.
Supported stub-types
Stubs can be simple or rich. Test Virtualization provides tools to create stubs with the complexity you require.
Stub-Type | Description |
---|---|
Basic |
There is a hard-coded single response for each specific input. |
Non-deterministic |
There are "n" hard-coded responses. A message switch is used to "switch" the response based on the input message. |
Data-driven (parameterized) |
There is input and/or output data specified in external data sources, for example, databases or spreadsheet files. |
Data model-driven |
There is input and/or output data in a data model that includes relationships among those data items. |
Behavior-driven |
Stubs can be extended with "behaviors" that are Java™ plug-ins that can respond to messages and proactively cause the stub to behave in a particular way. HCL® supplies some behaviors with HCL DevOps Test Integrations and APIs (Test Integrations and APIs) but customers can write their own. For example, a behavior can be used to make a stub act as a market data feed source. |
Deterministic |
This comprises a series of Receive Request/Send Response or Subscribe/Publish actions that are based on the message used to create the stub. |
Usage scenarios
During software development projects, functional and non-functional requirements can change quickly, and test environments and applications are often in high demand from other teams.
Test Virtualization can help because it enables you to:
- Continue testing when test environments are unavailable or not yet built.
- Test earlier and more often, reducing the cost of defects.
- Control the responses from services, enabling you to force the behaviour of the SUT.
In addition, Test Virtualization is designed to be used in all software test phases from unit testing to user acceptance testing:
- During each test phase, you should aim to test in as complete a way as possible. For example, when unit testing individual operations or services, you may not always have the interfacing components available to test against. Test Virtualization can be used virtualize those interfacing components.
- As you proceed from unit testing to integration testing and onwards, you will probably want to introduce more "real" components into the system under test. Virtualization enables you to reduce any risks that may be associated with the introduction of those real components.
The following table outlines example scenarios where Test Virtualization could be used.
Scenario | Description |
---|---|
Your testing project may be heavily reliant on integration with third parties or you want to control all systems with which the system under test (SUT) will communicate |
Integration with third parties can be immensely frustrating and costly. Test Virtualization can virtualize third party interfaces to enable you to test on your own terms according to your schedule. |
You have integration testing dependencies |
Parallel development can sometimes mean that some projects may not be ready to begin integration testing when your project is ready. Test Virtualization enables you to virtualize interfaces (even before they have been built) and continue testing. |
You want to run training or demonstration instances of applications without access to a large infrastructure |
For training or demonstration purposes, you may not require access to a production-size version of the system under test. In addition, you may not require access to any "downstream" applications. Test Virtualization can virtualize and simplify interfaces, ensuring that training or demonstration exercises do not impact any production systems. |
You want to test a database-dependent application with scrubbed and isolated data |
Test Virtualization can simulate databases as well applications. This means that you will have full control of all data to be used during testing. |
You want to provide a test system where none currently exists |
It may be too expensive to build a test environment and it may take too long to build it. Alternatively, there may be a test environment but it is being used by another team for the duration of your project. Test Virtualization substitutes for the "absent" test environment by virtualizing applications. |