The Events tab

With the Events tab, you can define how the stub will handle internally and/or externally received events.

Strictly defined, an event refers to a transition between two states. However, quite often, stubs will not use states, so an event can be regarded as the action that a stub will take when a message arrives on the operation for which you want to create a stub.

Note: This tab is not displayed when editing a deterministic stub.

The following topics describe how to use the buttons, lists table, and three tabs on the Events page.

Buttons and list table

The following table describes each button on the upper half of the Events page.

Table 1. Buttons on the Events page
Button	Description
Add Event	Clicking this button creates a new event for the currently selected operation.
Clone Event	Clicking this button creates a copy of the currently selected event in the list table.
Delete Event	Clicking this button deletes the currently selected event in the list table.
Move Event Up/Down	Clicking these buttons changes the list order of the currently selected event in the list table and consequently the order in which any guard conditions of any events listed in the table are evaluated while the stub is being executed.
Open operation referenced by event	Clicking this button opens the associated operations Operation dialog and changes the perspective from Test Factory to Architecture School.
Open data model referenced by stub	Clicking this button opens the data model (a comma-separated value (CSV) file), if any, associated with the stub. Note: You must use the Properties tab to associate a data model with the stub. (For information about using the Properties tab, refer to The Properties tab.)
Open data used by selection	Clicking this button opens any data associated with the currently selected event in the list table.
Advanced	Clicking this button toggles the display of fields on the list table between basic view and advanced view. Note: This button is available only in HCL DevOps Test Integrations and APIs (Test Integrations and APIs) 8.0.1 (or later). Note: A stub will be displayed in advanced view by default if data has been added to any of the columns that are displayed only in advanced view.

The list table on the upper half of the Events tab lists all the events contained in the stub.

When a stub receives an event, it searches the list of events from top to bottom to find an event that has been set up to handle the event received, based on the stubs current state. You can use message filters and guards if you want to ensure that the contents of a message determines whether and how an event is processed.

The following table describes the fields in the list table.

Table 2. Fields in the list table
Field	View	Entry	Description
From State	Advanced view only	Optional	This field enables you to specify an initial state for an event. For example, if you are building a stub that can track user sessions, you might want to have an initial state called `LoggedOut` for an operation `Login` operation. (The final state for the corresponding `Logout` operation might be `LoggedIn`.) Clicking the field displays a drop-down list that lists any states already defined for the stub and an Add new... option that enables you to create a new state. Clicking Add new... in the From State list opens the New State dialog. In the New State dialog, you must enter a name for the new state in the Name field. You can enter a description for the new state in the Description field but that is optional. Clicking OK closes the New State dialog. If this field and the To State field are left blank, Test Integrations and APIs will assume that this event will work for any state of the currently selected stub, so the stub will be stateless. You can also create a new state by clicking New next to the States field on the Properties tab. (The Edit and Delete buttons next to the States field enable you to edit and delete states as required.) Note: The From State field becomes editable only after an event has been selected.
Event	Basic and Advanced views	Mandatory	In computing generally, an "event" is something that happens that affects the system. In HCL DevOps Test Virtualization (Test Virtualization), an event refers to an operation. This field enables you to: Select one of the behaviours displayed on the Behaviour tab. For information on this, see The Behavior tab. Specify the operation associated with the currently selected event. When creating a new event, clicking this field displays a drop-down list that includes any operations already associated with the stub and a Browse option that enables you to select a different operation. Clicking Browse in the Event list opens the Select an Operation dialog box. In the Select an Operation dialog, select an operation from your projects logical resources and click OK. Note: This field is not editable until after an event has been selected.
Guard	Basic and Advanced views	Optional	This field enables you to specify conditions that will determine if an event will be handled. For example, you could create a guard based on the data held in a data model associated with the currently selected stub. Test Integrations and APIs tags can be used to create guard conditions. (For information about crating and using tags, refer to API Tester Reference.) Note: You must use the Input tab on the lower half of the Events tab to configure the guard condition of an event. (For information about using the Input tab, refer to The Input tab.) Note: This field is not available until after an event has been specified for the currently selected event.
To State	Advanced view only	Optional	This field enables you to specify a final state for an event. For example, if you are building a stub that can track user sessions, you might want to have a final state called `LoggedIn` for an operation called `Login`. (The final state for the corresponding `Logout` operation might be `LoggedOut`.) Clicking the field displays a drop-down list that lists any states already defined for the stub and an Add new... option that enables you to create a new state. Clicking Add new... in the To list opens the New State dialog box. In the New State dialog, you must enter a name for the new state in the Name field. You can enter a description for the new state in the Description field but that is optional. Clicking OK closes the New State dialog. If this field and the From State field are left blank, Test Integrations and APIs will assume that this event will work for any state of the currently selected stub, so the stub will be stateless. You can also create a new state by clicking New next to the States field on the Properties tab. (The Edit and Delete buttons next to the States field enable you to edit and delete states as required.) Note: The To field becomes editable only after an event has been selected for the event.
Pass- Through	Basic and Advanced view	Optional	Lists the action that has been specified for the event if there is no response.
Description	Basic and Advanced views only	Optional	This field enables you to enter a narrative description for the currently selected event. To enter a description for an event, select it and double-click this field. Note: This field is not editable until after an event has been specified.

Guard condition options

Guard conditions are Boolean expressions that affect the behaviour of a stub by enabling actions or events only when they evaluate to "TRUE" and disabling them when they evaluate to "FALSE".

The following table describes the Guard drop-down list options in the list table on the Events tab.

Table 3. Guard options
Option Button	Description
None	Click this option button (it is also the default) if you do not want to specify any guard conditions for the currently selected event. The Guard field on the list table will be blank if this option button clicked or if none of the Guard drop-down list options is clicked.
Record Exists	Note: This option is displayed only if there is a data model associated with the currently selected stub. Click this option button if a data model exists and you want to run the business logic/event if the record referenced by the incoming message exists. If this option is clicked, `Record Exists` will be displayed under Guard on the list table for the currently selected event. For a data model-driven message-based stub, `Record Exists` causes the stub to use mappings (from message contents to data model tag names) defined in the Message Editor when looking up records in the data model. If a record already exists, the `Record Exists` guard passes. If a record does not already exist, the `Record Doesn't Exist` guard passes. This enables you to have two events for an incoming message and to respond differently depending on whether the specified data is found. For example, if the service is "Find Customer" and the "Customer ID" field in the message is key field, customer data or an error message can be returned by using the two events and the guards without having to write the business logic.
Record Doesn't Exist	Note: This option is displayed only if there is a data model associated with the currently selected stub. Click this option button if a data model exists and you want to run the business logic/event if the record in the data model does not exist. If this option is clicked, `Record Doesn't Exist` will be displayed under Guard on the list table for the currently selected event.
Expression	Click this option if you want to specify a custom Boolean expression for the currently selected event. A collapsible Guard section is displayed in the Input section of the stub, initially expanded. For more information, see Guard conditions.
No Match	Click this option button if you want an events specified event (operation) to change state if a matching record is not found. If this option button clicked, `No Match` will be displayed under Guard on the list table for the currently selected event. Note: Essentially, no match is the default case of the message. For each operation, there can be only one event with the no match guard because it is invalid to have two default cases.