Stub creation by using the Recording Studio

Use the Recording Studio to create a message-based stub if you have access to a live system from which you can record events.

The HCL DevOps Test Integrations and APIs (Test Integrations and APIs) Recording Studio perspective provides Event Monitors, which you use to designate the parts of the environment to record. For example, you might record events relating to specific parts of the system infrastructure, or you might record events relating to specific services that use the system infrastructure.

Note: For general information about using the Recording Studio, including the use of proxies for recording events, see Using the Recording Studio.

You must model the environment in the Test Integrations and APIs Architecture School perspective (Logical and Physical Views) before it can be recorded. However, for many technologies, you need to model only the transports (for example, a web server or an IBM® WebSphere® MQ Queue Manager), so there is no need to define any operations.

While events are being recorded, they are displayed on the Events View of the Recording Studio perspective. You can add or remove Event Monitors, and filter which events are displayed in the Events View by selecting different monitors on the Event Monitors window.

Note: Recording events does not usually interfere with the operation of the system under test. For many (but not all) transports, events will still be dealt with in the same way that they would have been if Test Integrations and APIs was not being used. The only difference is that the events will be accessible through Test Integrations and APIs.

After you have completed recording events, you can use them to create any of the resource types outlined in the following table by saving the events and using the Save wizard provided.

Resource-Type Description
Unit tests The data within recorded events can be hard-coded into a unit test.
Integration tests The data within recorded events can be hard-coded into an integration test.
Stubs The data within recorded events can be hard-coded into a basic stub that always returns the same response.
Triggers Events can be reused in the form of triggers, which you use to simulate the system under test directly from Test Integrations and APIs.

You can then record what happens in response. However, this response is not necessarily the same as the one when you created the triggers, and you cannot validate any events recorded in response to the triggers.

Thus, you can send events to the system under test and bypass the GUI layer (and any other layers of the system that you might want to bypass) and determine how the system reacts to various inputs.
Requirements You can save a message for subsequent use but not specify how it will be used.

A requirement is an example message that can be viewed in the Test Integrations and APIs Test Factory perspective and optionally imported into other Test Integrations and APIs resources.
Operations If you have an incomplete model of the system under test, events recorded from the transports within the system can enable you to create new operations within your system model.
Important: Operation names are generated based on the information that is contained in the recorded events. The exact values can be modified in accordance with resource naming limitations, depending on the resource that you create.
Test data sets The data within recorded events can be entered into a data set, such as a comma-separated value (CSV) file, or a data model, which maps the relationships among data items in the system under test.

The following topics describe how to use the Recording Studio perspective: