 |  |  |  |  |  |  |  |
| Version 7.1.3 |
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.
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.
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 .
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" by setting
the option Priority for recording SmartIDs with qualifier to label,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 59 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 46.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 46.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 46.3 .
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:
#module=module1 references
a component with an extra feature named module
and the value module1.
#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 46.3 .
qfs:labelqfs: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".
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".
qfs:typeqfs: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 \.
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 46.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.
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.
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: 4/23/2024 Copyright © 1999-2024 Quality First Software GmbH |
