55.1 Mapping procedure structures

In the following we will look at the different requirements that procedures impose on definitions and how they are met.

Sequential node execution

In a procedure, nodes are executed one after another. The definition provides a sequential group for this purpose.

Specific nodes

Many procedures directly address specific components. In this case, node matching can be based on the node type and the QF-Test component ID or the corresponding SmartID, which is recommended. In any case, sufficiently unique specifications for the nodes are required, see section Criteria for identifying nodes.

Parameterized nodes

Many procedures use variables in their attributes. These variables can be entered in the definition under set procedure call parameters. The variable name is the name of the YAML entry. A placeholder for the attribute value is entered as the YAML value. For details please see Setting parameters in the procedure call. When nodes are later converted, a parameter with the variable name and the value of the attribute represented by the placeholder is added to the procedure call.

Order of definition evaluation

More complex procedures may contain the complete node sequence of another procedure. Since definition evaluation stops as soon as a matching definition is found, definitions for more complex procedures must be evaluated first. Likewise, definitions for procedures containing more specific nodes must be evaluated before those that contain a superset of those nodes. This can be controlled via the priority setting, see priority, and the order of nodes within the test suites.

An example of the latter case: two procedures where the first contains a mouse click on a component specified via QF-Test component ID, and the second contains a mouse click on a component whose QF-Test component ID is provided as a parameter. Here the definition for the first procedure must be evaluated first, because the definition for the second would also match the mouse click on the component specified in the first procedure.

Alternative node execution

For mapping an if/else or try/catch structure, the definition provides a choice group. You can specify any number of entries as alternatives within it. An entry can be either a single node or a node group - a sequential group, unsorted group, or another choice group, as needed.

Repetitions

Loops can be represented in the definition via repeat statements. They can refer to individual nodes or node groups. These must then appear consecutively in the node sequence to be converted. As node groups, sequential group, unsorted group, or choice group can be used. The repeat statement can contain minimum and maximum values. By default the repetition count is one.

Free order of nodes

In a procedure, nodes are necessarily executed in a specific order, but from a business logic perspective this may not actually be required. This also means that users may not record them in exactly that order, or that they may appear in a different order in existing test cases. A definition must therefore provide a structure that encloses a group of nodes that can appear in any order. This is represented by an unsorted group.

Within an unsorted group it is possible to specify for each individual node how many times it can or must appear in the node sequence described by the unsorted group (minimum and maximum occurrences). By default, nodes are assumed to be optional but can appear any number of times.

Non-recordable nodes

Procedures often contain nodes that cannot be recorded. If the conversion to procedure calls is intended to happen directly after recording, such nodes are not relevant for the definition. They can either be omitted entirely from the definition or marked as optional, see Optional nodes. The latter is useful when node sequences in existing test suites are also to be converted.

In the following chapters we will explain how all these requirements can be fulfilled using the YAML syntax of the Procedure call definition node.