55.5 Criteria for identifying nodes

YAML section node

Definition-relevant nodes must be written with sufficient precision: Only then the nodes can be matched correctly to a particular definition in the conversion process.

This section explains which node information can be used for this purpose, in which YAML sections it is entered, and how Automatic creation of procedure call definitions populates these sections.

55.5.1 Node type

YAML section node type

Here you specify which type of event is expected, for example MouseEvent, TextInput, KeyEvent, or CheckStep.

55.5.2 Node attributes

YAML section attributes

Here you can specify which attribute values should be checked in the nodes to be converted. For Check nodes this could be the Check type identifier or Expected state, for Mouse events the Modifiers. The QF-Test component ID attribute plays a special role:

YAML entry component id

The QF-Test component ID fully identifies the component. If it is specified, no entries need to be made in the component section.

During node conversion, only the QF-Test component ID of the respective node is then compared. It must match exactly, including index specifications. If these should be ignored or entered as parameters in the procedure call, the QF-Test component ID without index specifications must be entered in the component section under id.

The exact comparison means that when using SmartIDs, the nodes to be converted must also use SmartIDs - and vice versa when SmartIDs are not used.

There is another situation where using component id in the attributes section may not work: when the option Name override mode (record) was sometimes set to Name hierarchy and sometimes to Name overrides everything during component recording. Cleaning up the components would be the right approach, but to save the effort it is often simpler to set the option to Name overrides everything. This works for test execution, but poses a challenge for creating definitions.

For these reasons, the automated creation of definitions writes component information into the component section.

55.5.3 Component values

YAML section component

As an alternative to specifying the QF-Test component ID under component id in the attributes section, the criteria describing the component can be stored in the component section. The QF-Test ID also plays a key role here:

An QF-Test ID is available

Specifying the id makes it unnecessary to specify the remaining criteria - except for sub-indexes, which are never part of the id here and are always specified in the subindexX section. The second exception is scope, which may be relevant when the option Name override mode (record) is set to Name overrides everything.

Specifying a SmartID implicitly provides the identification criteria (class, name, feature, extra features). When using a nested SmartID, the parent components of the nodes to be converted are also checked against the specifications.

When the QF-Test ID refers to a Component node in the classic way and the option Name override mode (record) is set to Name hierarchy, the nodes to be converted are checked to see whether they refer to exactly the same component. If the option Name override mode (record) is set to Name overrides everything, or the node to be converted specifies a SmartID, the check reads the Class name and Name of the referenced expected Component node and compares them with the Class name and Name of the component or SmartID referenced by the node to be converted.

The QF-Test ID is not available

If the QF-Test ID cannot be used for node identification, you can specify Class name, Name, Feature, and any Extra features. scope and sub-indexes can also be specified.

During conversion, these are evaluated in the following order: first classes, then - if specified - name. If no name is given, feature and extra features are compared. If the class check fails to match the value in the Class name attribute, the extra features qfs:type, qfs:class, qfs:genericclass, and qfs:systemclass are also taken into account. scope and sub-indexes are always evaluated.

55.5.4 State conditions

YAML section condition

For definitions intended to be evaluated directly after a recording, you can also query certain states of the GUI component that are present in the recording information but are not saved in the node itself. These states are checked, editable, enabled, selected, and visible. The values can be used via Placeholders in expressions of the respective Script language.