5.6

SmartID

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

In February 2024, a special webinar took place about SmartID. Here you can find the special webinar video recording available on our QF-Test YouTube channel.

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 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.

The SmartID is characterized 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.

Typically, the SmartID consists of #, followed by the class of the component delimited by a colon. When the SmartID value is a label, a qualifier and = come after the colon, then the value of the SmartID. For example #TextField:left=username.

The qualifier denotes the type of the SmartID value. When replaying a SmartID without qualifier the option Priority for recording SmartIDs with qualifier sets the priority for the recognition criteria. The following qualifier exist:

• name: Name, see as well SmartID syntax for Name. By default, the qualifier will not be recorded.
• feature: Feature, see as well SmartID syntax for Feature. By default, the qualifier will not be recorded.
• label: Feature is a special form, accepting feature or one of the qfs:label* variants. By default, the qualifier will not be recorded.
• The names of the Extra features, respectively their short forms, for example qlabel for Best label. See as well SmartID syntax for Extra features. By default, the respective qualifier will be recorded.

Specifying the class and the qualifier help with readability and performance. The option Always record class for SmartID influences whether the component class will be recorded. The option only has effect on components where the class belongs to one of the Generic classes. With other classes it is mandatory, for example #DIV:compid.

The SmartID takes the place ot the 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.

Note For a brief introduction to SmartID, also read our blog post SmartID - The next generation of component recognition .

5.6.1

Use cases 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" by setting the option Priority for recording SmartIDs with qualifier to label,name.

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.

5.6.2

SmartID syntax for Class name

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

You do not need to specify the class in the SmartID when you address a component typically used in tests. It is sufficient to specify the Component identifiers or a component label (either Feature or one of the qfs:label* variants), for example #btnOK, where "btnOK" is the identifier of the button, or #Save, where "Save" is the label of the Button. It makes the handling of the SmartID easier. However, to a certain extent at the expense of performance, as without a specified class QF-Test has to check more candidates for matches.

Because of better performance QF-Test records the class with the SmartID by default. If you want to suppress it, please set the option Always record class for SmartID to 'false'.

chapter 61 documents the properties for each class, including where you have to specify the class with a SmartID. Any class not mentioned in the chapter has to be specified in the SmartID, too. Example: #DIV:addresses where "addresses" is the Name of the DIV element in a web application.

Panels with a label are a special case, being useful for nested SmartIDs (see subsection 5.6.7) or scopes (see section 5.7). For this reason the class type Panel:TitledPanel belongs to the SmartID classes and does not need to be explicitly specified.

If you use a predefined class type in addition to the generic class, you can write this combination as usual, for example #Button:ComboBoxButton:. You can find the prefedined class types in 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 48.3. .

5.6.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 48.3 .

5.6.4

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 48.3 .

5.6.5

SmartID syntax for Extra features

Recognition criteria from the group of Extra features are also available for SmartIDs. They can be referenced via qualifiers inserted before the SmartID value. An equal sign = separates the qualifier and the SmartID. For all Extra features the name of the extra feature corresponds to the qualifier. They are case-sensitive. The SmartID value corresponds to the value of the extra Feature, also case-sensitive.

Examples:

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

Short forms exist for the qualifiers for qfs:label* variants. They will be explained further down in the chapter.

SmartID specific special characters ":", "@", "&" und "%" (see SmartIDs - special characters) in the value, the qualifier or the class name of the SmartID have to be escaped with a prefixed \.

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

Extra feature qfs:label

qfs:label* variants representing the labels of a component have prominant role for component recognition. When a component has labels use can use either the Best label or a specific label. The advantage of a specific label is performance at replay, because QF-Test knows which label to go for and does not have to check all possibilities. When you want to reference a specific label you need to write the hash tag, # then the qualifier, i.e. the short form of the name of the Extra feature (see qfs:label* variants), followed by "=" and the SmartID value, for example #left=First name. You can address the best label directly after the hash tag or via the qualifier qlabel=. When you write #label=, the value of the SmartID can either refer to the Feature or one of the qfs:label* variants. The qualifiers are not case-sensitive. SmartIDs without a qualifier, for example #First name will be evaluated following the priority set via the option Priority for recording SmartIDs with qualifier, by default Name - Feature - 'Best label'.

Beispiele:

• #left=First name - The label to the left of the component has to be "First name".
• #qlabel=First name - The Best label for the component has to be "First name".
• #label=First name - Either the Best label for the component or the Feature has to be "First name".
• #First name - Either the name or the Best label for the component or the Feature has to be "First name".

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 qualifier text=. If you want to explicitly use qfs:text you can use qtext=.

Examples: #text=Anna, #qtext=Benno

Note Looking closely, with the qualifier #text= QF-Test will first look for the Extra feature #qfs:labelText=, then for qfs:text and text. As the latter two have a special use with text components for which nor #qfs:labelText= will be recorded, there won't hardly be any conficts.

If you want to use the extra features qfs:text and text without the prefix #text= you need to set the option Priority for recording SmartIDs with qualifier accordingly, for example to "name,feature,qlabel,text".

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 Generic classes) any colons contained within must be escaped via \.

5.6.6

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>

5.6.6.1

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 48.3.

5.6.7

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.

5.6.8

Recording and replaying SmartIDs

To record SmartIDs instead of component notes, please activate the option SmartID recording or simply check the menu item »Recording«-»SmartID recording«.

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.

Note For many cases recording SmartIDs is straightforward. However, depending on the target component and the information available it may happen that no SmartID can be recorded so that a classic Component node node gets recorded instead. 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 nor the extra feature qfs:label* variants.

By default the generic class is prefixed to the recorded SmartID. This not only improves readability, it also has a significant effect on replay performance. This can be turned off via the option Always record class for SmartID. Please note that the 'Label' or 'Panel' prefixes are always recorded to ensure correct replay.

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.

5.6.9

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.