Tutoriel en version vidéo: Nous vous guidons pas à pas à travers QF-Test...
Version 8.0.1 |
Since version 7.0 QF-Test officially supports SmartIDs allowing you to reference a component without having to record a 'Component' node.
For some applications SmartIDs may reduce the time required for management and maintenance of the component information considerably.
SmartIDs may also have a positive effect on readablity and maintainability of the tests themselves.
It also allows you to write tests without use of the recording functionality, for example when a component or even the whole application does not yet exist, and you want to go ahead with tests ("test first" approach). SmartIDs then allow you to specify the future recognition critiera directly.
The recognition criteria available are the component class, the name or a label and the index. The values are the same as in the recorded 'Component' node. Nested SmartIDs even reflect the component hierarchy.
The SmartID is used in place of the QF-Test ID of the component.
SmartIDs start with the hash symbol #
as the first character,
in the simplest form followed by the name or the label of the component,
for example:
#btnOK
, "btnOK" being the name of the component or
#First name
, "First name" being the label of the component.
The disadvantage of this simple form of the SmartID is performance at replay, as QF-Test has to search all components for the given criteria. For this reason it is better to specify the class of the component, too. Above SmartIDs would then be:
#Button:btnOK
#TextField:First name
Currently, the recording of SmartIDs is not activated by default. You can activate it directly via the menu.
Now, please record some SmartIDs by
You will find the recorded mouse clicks in the 'Extras' section.
The SmartID for the input field is #TextField:name=DiscountValue
,
because QF-Test preferably uses the name for the SmartID value when
there are a name and a label for the component.
The second mouse click shows the SmartID for the table component, followed by
@
and the text index of the column and &
with the numeric index of the row, just like you saw it in the one but
last section:
#Table:name=VehicleTable@Modell&0
.
Of course, you can continue working with SmartIDs. When recording more SmartIDs you will come across more expressions used in SmartIDs. We now want to show you some of them and give you an explanation why they are used.
For labels ending with a colon you will find a back slash in front of the colon:
#TextField:First name\:
The explanation is the colon defines the end of the name of the class. Therefore, colons
in the component name or the label have to be escaped by a back slash.
Other characters like @
, &
and
%
have to be escaped as well because they are used as
separators before indices.
Labels will be prefixed by a qualifier, here left=
:
#TextField:left=First name
Explanation: a SmartID consisting of class and name of the component reaches the same performance at replay as does component recognition via a recorded 'Component' node. Labels, however, are a different case. There are various options for what might be the best label for a component. QF-Test searches all the available labels of a component for the best one. For performance it is good when you specify the type of label expected.
left=
indicates the label to the left of the component.
Other SmartID qualifiers indicating the position of the label are
right=
, top=
, topleft=
or bottom=
.
When the text of the component serves as label the qualifier is
text=
, for the tooltip tooltip=
.
When you get several components with the same name or label on a
display you might see a compound SmartID consisting of to
single SmartIDs concatinated by @
:
#TitledPanel:Customer address@#TextField:left=First name
#TitledPanel:title=Invoice address@#TextField:left=First name
The example shows the SmartIDs for the label "First name", both on the panel "Customer address" and on the panel "Invoice address".
The second sample is a bit more performant than the first one because of
the qualifier title=
in the SmartID for the panel. With the
first one readablity is a bit better. It depends on the application whether
you have to pay attention to performance. With web applications with many
UI elements it is usually an issue. However, with Java applications you
can opt for readablity in most cases.
Long labels can be shortened by the use of regular expressions:
#%Dialog:Information.*@#Button:OK
The percent sign directly after the hash sympol indicates the name or the label to be a regular expression. In above sample the regular expression shortens the title. It may also be used to identify an "OK" button in any dialog with the title starting by "Information". For more details about regular expressions please see the manual - regular expressions. You will find more information about components and SmartIDs in manual - components.
Last update: 9/10/2024 Copyright © 2002-2024 Quality First Software GmbH |