 |  |  |  |  |  |  |  |
| Version 6.0.5 |
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.
The application areas are generally the same as those of Generic components. SmartIDs mostly replace generic components and are easier to use.
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:
| ||||
| Example 5.1: Changing the recording order of recognition criteria for SmartIDs | ||||
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. For a list of such classes please
have a look at subsection 45.5.1.
For components of one of those classes the SmartID may simply consist of the
identifier (subsection 5.4.2.1) or the label of the
component (either the Feature or
the extra feature qfs:label).
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. Any classes not
contained in the list have to be specified explicitly in the SmartID,
for example #Panel:addresses, where
"addresses" is the name of the panel.
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 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 45.3. .
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 45.3 .
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 45.3 .
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:
#tooltip=Please fill out references
a component with an extra feature named tooltip
and the value Please fill out.
#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 45.3 .
qfs:labelqfs: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.
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
qfs:typeqfs: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 \.
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>
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 45.3.
The Component hierarchy can also be used with SmartIDs
for recognition. As divider between hierarchy levels, @ is used.
Examples:
#Customer information@#Name
references a component with the SmartID #Name
in a parent component (like a TitledPanel) with the SmartID
#Customer information.
#ComboBoxSmartID@#Button:#ListSmartID&22@#Link:<1>#Link:<1> addresses the second link inside.
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.
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.
| | | | | | | Last update: 3/15/2023 Copyright © 1999-2022 Quality First Software GmbH |
