The class of a component is a very important attribute as it describes the type of the recorded component. Once QF-Test records a button, it will only look for a button on replay, not for a table or a tree. Thus the component class conveniently serves to partition the components of a GUI. This improves performance and reliability of component recognition, but also helps you associate the component information recorded by QF-Test with the actual component in the GUI.
Besides its role in component identification, the class of a component is also important for registering various kinds of resolvers that can have great influence on the way QF-Test handles components. Resolvers are explained in detail in subsection 52.1.7.
The 'Name' is used here for generating the 'QF-Test component ID'. Examples for this can be found in How to judge robust component recognition.
Each UI toolkit usially defines its own system-specific classes for components like Buttons or
Tables. In case of Buttons, that
definition could be
javax.swing.JButton for Java Swing, or
org.eclipse.swt.widgets.Button for Java SWT, or
javafx.scene.control.ButtonBase For JavaFX, or
web applications. In order to allow your tests to run independently of
the utilised concrete technology QF-Test unifies those classes via
classes, for example all buttons are simply called
You can find a detailed description of generic classes in chapter 59. In addition to the generic class, systen specific classes are recorded as 'Extra features', but with the status "ignore". In case of recognition problems because of too many similiar components, these can be enabled to sharpen recognition, even if detracting from flexibility.
JavaFX Even if the class was extended, the generic class will be recorded. Additionally, it should be mentioned that this concept allows QF-Test to easily create tests with obfuscated classes without having to change the default settings. During replay, QF-Test compares the recorded 'Class name' attribute of the component with each class of the object in the SUT. Therefore, QF-Test can handle class name changes as long as the base type remains the same.
HTML is a very flexible language to describe content and structure of a website.
There is only a minimum of quasi-standards like
for which you can always expect the same functionality
and which can therefore be assigned to a QF-Test class by default.
The development of web applications usually happens via toolkits which use their own standards.
QF-Test includes class mappings for a range of commonly used toolkits, see Special support for various web frameworks.
If the developers of the application extended a toolkit or used a custom one,
it will be neccessary to announce the class mapping to QF-Test.
This is described in Improving component recognition with a
If QF-Test can assign a component a generic class, this will gain the following advantages for test creation and execution:
If the functionality of the component is known, the most suitable recognition criteria can be stored.
Example button: The button label is the first choice for the 'Feature' and the extra feature 'qfs:label'.
Example text field: It does not make sense to use the text value for recognition. Instead, QF-Test searches for a label nearby and stores this in the extra feature 'qfs:label'.
The generic class itself also is a differentiation criterium.
This is especially noticeable in web applications,
where most components will be recorded with the class
matching their HTML tag by default.
The generic class also influences the optimal mouse position during event replay.
Example button: The mouse click is ideally placed in the middle of the button.
Example text field: The mouse click is ideally placed in the same place where the tester clicked during recording, so text can be inserted in exactly the same place if needed.
|Last update: 2/26/2024
Copyright © 1999-2024 Quality First Software GmbH