Server-based stubs

You can find information about the ways in which the stubs are managed in HCL DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) 9.2.1 or later.

Earlier to 9.2.1, a stub that was authored and published to the server was shown in the hierarchical view of components and operations and was a one-to-one presentation of the stub definition that came from HCL DevOps Test Integrations and APIs (Test Integrations and APIs). Also, all configuration settings were to be specified as part of the request to start a stub.

In Test Virtualization Control Panel 9.2.1 or later, the way in which stubs are worked with has changed. Stubs are now a representation of both their definition (published from Test Integrations and APIs) and the server-based configuration settings that is used when the stub is started. You must use both when the stub is started and managed by Test Virtualization Control Panel. You can now pre-configure the settings that you want to use before you control the execution of the stub. A server-based stub remains in the dashboard with its current settings while new versions of the same definition are published and older versions are removed when projects are deleted in the administration page. The server-based stub continue to remain in the dashboard until all versions of the underlying definitions are removed.

When you publish a stub definition from Test Integrations and APIs, a server-based stub with a default configuration is created in Test Virtualization Control Panel.

Note: When you republish a stub (either at the same version or a different version), the server managed settings of the stub are not affected.

For example, when you publish a new stub, a server-based stub with a default configuration that is based on the settings in the stub definitions is created in Test Virtualization Control Panel. The default configuration is associated with the published stub and made available on the server. When you change any of the stub definitions and republish the stub (either at the same version or a different version), then only the stub definition is updated in the version of the stub republished or a new stub is added at a different version.

Pre-existing stub definitions that are present in the server earlier to 9.2.1 are also migrated as new server-based stubs with default configurations. Interactions with pre-existing stub definitions are adapted to the new model in 9.2.1 and are displayed as externally-created instances of running stubs in the Environments Dashboard, where they remain in this state until they are stopped in Test Virtualization Control Panel. For example, you can by using the Test Integrations and APIs command-line client, start a pre-existing stub definition along with its configuration settings, resulting in the creation and starting of an instance of the stub in Test Virtualization Control Panel (displayed as an externally-created running stub instance in the Environments Dashboard).

The following stub definitions become server-based stubs:

Stub definitions published from Test Integrations and APIs 9.2.1 or later.
Pre-existing stub definitions that are migrated from Test Virtualization Control Panel 9.2.1 or earlier, are automatically displayed in the RUNNING state.

The following stub definitions become managed stubs:

Stub definitions of both new and existing stubs that are published from the IntegrationTesterCmd tool.
Migrated stubs from Test Virtualization Control Panel 9.2.1 or earlier, which are started after the running stubs are stopped.

If the stubs are available on Test Virtualization Control Panel and you start the stubs, the result can be as shown in the following table:


Stub existing as a result of:	If you start the stub definition from:	Result
Stub definitions published from Test Integrations and APIs 9.2.1 or later. Pre-existing stub definitions migrated from Test Virtualization Control Panel 9.2.1 or earlier, and are in the `STOPPED` state.	Test Virtualization Control Panel	The same stub is started. The running stub is displayed with the icon.
	IntegrationTesterCmd by using the switch-on stub options	Another instance of the stub with the same name and configuration parameters is created on Test Virtualization Control Panel. The running stub is displayed with the icon.
	IntegrationTesterCmd by using the start stub options	Another instance of the stub with the same name and configuration parameters is created on Test Virtualization Control Panel. The running stub is displayed with the icon. Note: The stub is displayed only when it is in the `RUNNING` state and is removed from the Environments Dashboard when the stub is stopped.