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.

In a SmartID components can also be directly addressed via their 'Names', without recording a 'Component' node.

The influence of the class on the 'QF-Test ID' of the component is described below, usage as SmartID in section 5.6.

Generic classes

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 INPUT:SUBMIT for web applications. In order to allow your tests to run independently of the utilised concrete technology QF-Test unifies those classes via so-called generic classes, for example all buttons are simply called Button now.

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.

Web HTML is a very flexible language to describe content and structure of a website. There is only a minimum of quasi-standards like INPUT:SUBMIT, 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 CustomWebResolver.

If QF-Test can assign a component a generic class, this will gain the following advantages for test creation and execution:

Independence from concrete technical classes
With generic classes, a certain independence from the concrete technical classes is established. This concept allows you to create tests independent of the concrete technology.
Improved component recognition

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 DIV, matching their HTML tag by default.

Optimal mouse position during replay

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.

Class-specific checks
In addition, QF-Test offers additional class-specific checks during recording. For example, text fields can be checked for their editable state. 'Check items' however only make sense for lists, tables or trees.