SmartID (Preview)

6.0+Preview "Preview" means the feature will be officially released in a future version. At this point the feature is not fully implemented, but development has reached a point where it is already of great use and the released functionality can be relied upon without concerns about backwards compatibility.

SmartIDs enable a flexible, easy recognition of components without storing the recognition criteria. This noticeably slims down the recorded component tree in "Windows and Components". When using SmartIDs only, the component tree is not used at all anymore. However, you have to consider the price of this flexibility and ease and the possible - depending on the situtation - impact on performance and maintainability.

SmartIDs use the same recognition criteria which are stored during classic component recognition in a 'Component' node. The difference is that, of all the possible recognition criteria, one or multiple are explicitly selected and entered in place of the reference to a recorded 'Component', for example, directly in the attribute 'QF-Test component ID' of a mouse click node.

The SmartID is denoted by a leading #. The simplest version of a SmartID is either the name or the label of a component with a prefixed #. For example, #username to select a component with the name username or #User name if User name is the label of the component.

The goal of SmartIDs is to slim down the component tree - which is useful, but not at all costs. The idea is to keep simple things simple, but if addressing a component gets difficult, 'Component' nodes are preferable. As an alternative you can handle issues of uniqueness or performance via the scope concept as shown in Scope (Preview).

The SmartID will be entered in the attribute 'QF-Test component ID', for example in the 'QF-Test component ID' attribute of event or check nodes. It can, just like the 'QF-Test component ID', be stored in variables, passed in parameters, or used in scripts. For complex components like tables, lists or trees, the SmartID can also replace the 'QF-Test component ID'. The index describing the child element remains unchanged. Following a SmartID, a child component can be addressed either via another SmartID or an XPath, see Addressing via XPath and/or CSS selectors.

SmartIDs can be used with all client technologies.

As with generic components you need to consider that updating a component is not as comfortable as with a 'Component' node. However, QF-Test provides a powerful "Search and Replace" feature, which can also be used to bulk-modify SmartIDs.

Areas of application for SmartIDs

The application areas are generally the same as those of Generic components. SmartIDs mostly replace generic components and are easier to use.

Readability

When directly recording test cases, the use of SmartIDs can make recorded event and check nodes more readable. Especially if the recorded component names are cryptic and stable labels are available, it makes sense to change the recording order of recognition criteria to "First label, then name" using, for example, a server script:

rc.setOption(Options.OPT_RECORD_SMARTID_PRIORITIES, "label,name")
Example 5.1:   Changing the recording order of recognition criteria for SmartIDs

Ignoring the component hierarchy
Some applications have deeply nested component hierarchies. SmartIDs make it easy to reduce the component tree, which is especially helpful if the hierarchy is not stable across versions. (Until now, Generic components were used in these cases. This is still possible, even in parallel to SmartIDs.)
Test-driven development
For test-driven development, SmartIDs offer the big advantage of not having to create any 'Component' node nodes. In addition, Component identifiers are often defined in the technical design during test-driven development. These can then be used for test creation.
Keyword-based tests
Keyword-based tests are implemented via procedure calls and parameters. The test creator does not record components and depends on visual information from the GUI to identify components. This could be the component label or its function (class). Further information can be found in Keyword-driven testing with QF-Test.
Integration with other testing tools
When controlling test execution in QF-Test via other testing tools like Robot Framework, the recognition criteria can be specified directly via SmartIDs.

SmartID syntax for 'Class name'

The Class is specified in the SmartID directly after the # and followed by a :, for example #Button:.

If you use a predefined class type in addition to the generic class, you can write this combination as usual, for example #Panel:TitledPanel:. You can find the prefedined class types in Properties of generic classes. For your own class types, any internal colons must be escaped via \, for example #Panel\:myPanel:.

You can find more information about the combination possibilities in section 44.3 .

SmartID syntax for 'Name'

A Name can be specified in the SmartID directly after the #, for example #txtUsername. If the class of the component belongs to the Generic classes, just stating the name is sufficient. Otherwise, the Class must be prefaced, for example #DIV:txtUsername.

The name can contain SmartID-specific special characters , but they must be escaped with a prefixed \.

To force component recognition to refer to the Name, the SmartID can be prefixed with Name=, for example #Name=txtUsername. Upper/lower casing does not matter for Name=.

You can find more information about the combination possibilities in section 44.3 .

SmartID syntax for 'Feature'

The recognition criterium Feature can be specified in the SmartID directly after the #, for example #User name. If the class of the component belongs to the Generic classes, just stating the name is sufficient. Otherwise, the Class must be prefaced, for example #DIV:User name.

The feature can contain SmartID-specific special characters , but they must be escaped with a prefixed \.

To force component recognition to refer to the Feature, the SmartID can be prefixed with Feature=, for example #Feature=User name. Upper/lower casing does not matter for Feature=.

You can find more information about the combination possibilities in section 44.3 .

SmartID syntax for 'Extra features'

Recognition criteria from the group of Extra features are also available for SmartIDs.

Here, too, SmartID-specific special characters , must be escaped with a prefixed \.

A special role is given to the additional feature qfs:label, which contains the das die determined label of the component. It can be specified in the SmartID directly after the #, for example #User name. If the class of the component belongs to the Generic classes, just stating the name is sufficient. Otherwise, the Class must be prefaced, for example #DIV:User name.

For all other extra features, the name of the extra feature must be specified, followed by = and the value of the extra feature. Upper/lower casing must be preserved for the name of the extra feature.

Examples:

  • The SmartID #tooltip=Please fill out references a component with an extra feature named tooltip and the value Please fill out.
  • The SmartID #my\:foo=Any\&thing references a component with an extra feature named my:foo and the value Any&thing.

You can find more information about the combination possibilities in section 44.3 .

Extra feature qfs:label
To force component recognition to use qfs:label, prefix the SmartID with qlabel=, for example #qlabel=User name. (qlabel= was introduced to avoid the more cumbersome notation #qfs\:label). If it does not matter whether the feature or the extra feature qfs:label is used, Label= can be prefixed, for example #Label=Anwendername. Upper/lower casing does not matter for the Label= and qlabel= prefixes.
Extra features qfs:text and text

The extra features qfs:text and text have a special status as well. Both can be addressed via the prefix text=. If you want to explicitly use qfs:text you can use qtext=.

Examples: #text=Anna, #qtext=Benno

Extra Feature qfs:type
The extra feature qfs:type denotes the type of a class. If a type is not predefined by QF-Test (see Properties of generic classes) any colons contained within must be escaped via \.

SmartID with index

All SmartIDs can be equipped with an index in case multiple components match the same SmartID. For this, the technical order of the components in the hierarchy counts. This does not have to be the same as the visual order. The count of the index starts at 0. The index is specified in between angled brackets. If no index is given, 0 is used implicitly.

Examples: #Name<2>, #TextField:<2>

Special cases

For components of the class Label, the standard order does not apply. Because they are mostly used as label for other component classes and are stored there in the feature or extra feature "qfs:label", components of the class Label are treated as subordinate. Label components must be addressed explicitly with the prefixed class Label:, for example #Label:First Name.

You can find information about the SmartID syntax in general in section 44.3.

SmartID syntax for component hierarchies

The Component hierarchy can also be used with SmartIDs for recognition. As divider between hierarchy levels, @ is used.

Examples:

Component inside container
The SmartID #Customer information@#Name references a component with the SmartID #Name in a parent component (like a TitledPanel) with the SmartID #Customer information.
Component inside "normal" component
Sometimes, components like a Button will not have any good recognition criteria themselves but can be addressed well via their parent component.
A typical example is the Button for expanding the list of a combo box:
#ComboBoxSmartID@#Button:
Component inside Sub-Element
Links or buttons inside list oder table elements can be addressed with nested SmartIDs:
#ListSmartID&22@#Link:<1>
Here, the part before "@" addresses a list element, #Link:<1> addresses the second link inside.

Recording and replaying SmartIDs

If you want to record SmartIDs, check the menu item »Recording«-»Record SmartIDs« or the preferences setting 'Record SmartIDs' in section »Recording«-»Components«.

Preview For QF-Test recording SmartIDs is technically sophisticated. At QFS we require more practical experience with existing applications in order to implement suitable options for fine-tuning. Currently it may happen that no or non-optimal SmartIDs will be recorded.

When recording SmartIDs, QF-Test first checks if a Name is present. If it is, it will be used for the SmartID. If not, QF-Test searches for a label (in Feature or Extra features). If the determined SmartID is valid for multiple components, an Index is attached.

In SmartID recording mode, every time a GUI element is recognized as not suited for SmartIDs, it will be recorded as a classic 'Component' node node. This is the case if, for example, the GUI element cannot be assigned a generic class or if QF-Test can determine neither a Name nor a Feature or the extra feature qfs:label.

If a component of class 'Label' is recorded, 'Label' will always be prefixed on the SmartID (because otherwise, the component labeled by this 'Label' component would be referenced instead). Example: #Label:Street.

Replaying nodes with SmartIDs is no different than with recorded components. Both variants can be used inside the same test case. SmartIDs can also be used in combination with recorded components to address descendant components. The example recordedList&10@#Button: illustrates the combination of the 'QF-Test ID' of a recorded list with an Index and the SmartID of the Button contained inside the list element.

Component 'QF-Test ID' as SmartID

It is possible to set the 'QF-Test ID' of a recorded 'Component' to a SmartID icluding prefixed #. This can be used to essentially reroute this SmartID and perform the recognition via the classic recognition criteria of the recorded component. Recording individual components makes the most sense if the SmartID gets long and cumbersome, has bad performance, or is hard to make unique. The SmartID indicator # can be used for consistency's sake, but it does not have to be.