Tutorial

Video Icon

In the near future we will upload videos for every chapter of the tutorial which will lead you step by step through QF-Test.

13.2
'Windows and components' Section

QF-Test stores the information about how to find a component in the GUI of the SUT in the 'Windows and components' section. It analyzes the component information during the recording of actions to the SUT and saves the information for the components the user interacted with in the details of the 'Component' nodes.

This section is meant to give you an idea about which kind of information is stored in the 'Component' nodes and how QF-Test uses it to recognize a component in the GUI. There are two cases where you will want to have a look at components and where it will be useful to have a basic idea of the concepts of component recognition.

The first one is when the GUI of your application changed significantly between when you first recorded the component to when you want to replay the test, e.g. because of a new release of the application. QF-Test uses several algorithms to evaluate whether a certain GUI element currently displayed matches the criteria of the GUI element that was once recorded. However, when too many of the criteria no longer fit then you will have to have a look at the components. For a detailed instruction about what to do then, please refer to the manual chapter Troubleshooting component recognition problems. There are also links to videos showing respective samples.

The second one is when you want to improve component recognition. As you already know from the chapter Improved Web Component Recognition a certain functional component like a checkbox or table, even an input field, can be implemented in quite a number of different ways from the basic HTML components available. Even though QF-Test provides component recognition for a number of AJAX toolkits there may always be some components that are not recognized for what they really are. For details about how to implemtent additional component recognition please have a look at the chapter 'CustomWebResolver' in the technical reference part of the manual.

Let's have a look at a 'TextField' component node and see which criteria were recorded and saved in the details of the 'Component' node.

  • Action Start the CarConfig application, in case it has not been started already, by executing the 'Setup' node of the test-suite.
  • Open the procedure 'Check final price'.
  • Navigate to the text field 'Component' node by right-clicking the text check node and selecting »Locate component« or using the [Ctrl-W] shortcut.
Popup-menu
Figure 13.2:  Locating a component

This is going to take you directly to the 'TextField CalculatedPrice' node in the 'Windows and components' section.

component tree
Figure 13.3:  Component tree

Above component tree has only a few levels. This is because of the custom web resolver registered after the start of the application as explained in Improved Web Component Recognition. When you have a look at the component tree recorded for the test-suite you set up in chapter 11 you will notice that there are a lot more DIV levels. These have been defined on the HTML page. They are not relevant for component recognition and make the tree rather big and confusing. Therefore, in the demo test-suite, we suppress their recording with the custom web resolver.

Let's have a look at the properties of this component node used to identify the GUI element.

Component details
Figure 13.4:  Details of the 'Component' node

The topmost attribute is 'QF-Test ID', which provides the 'handle' to the component to be used in the test-cases and procedures. All other attributes refer to the component in the GUI.

The next attribute is 'Class name'. In our case it is 'TextField'. For component recognition it is essential to know the class of a component. In fact this class is a generalized value of the Java class or Java system class. This is helpful to achieve recognition independently of the specific implementation and allows an easy porting of tests e.g. from Java Swing to its successor JavaFX. However, QF-Test saves the specific and the system class in the 'Extra features' table as 'Extra features' named qfs:class and qfs:systemclass. By default, they are not used for component recognition.

Other examples for classes would be 'Panel', 'Dialog' or 'Button'.

The 'Name' attribute is the name or id given to the GUI component by the programmer. If there is a Name then this, together with the class, is all QF-Test needs to identify a component in the GUI.

If the programmer did not set a name or id for the GUI component and the 'Name' attribute therefore remained empty QF-Test needs other criteria like a certain text associated with the component, index information and geometry.

A feature associated with a button for example would be the text shown on the button. QF-Test saves a text directly belonging to the GUI component in the 'Feature' attribute. If the web GUI element has not text but an id QF-Test saves the id in the 'Feature' attribute. If none of the two exists and there is a text in the vicinity of the component that could be the label then this will be saved in the 'Feature'. In any case the label will be saved in the 'Extra features' table with the 'Extra features' Name qfs:label.

The Structure information refers to all GUI components of the respective class. The total number of GUI components of that class is saved in the 'Class count' attribute, the index of the component itself in the 'Class index' attribute.

Last there is the Geometry information. It is the one having the lowest weight within the recognition algorithm. It can be of value if no other helpful information is available for a component.

In case you are interested in further details of the component recognition you will such in the Component recognition chapter of the technical reference of the manual.

If you want to get a feeling for the component recognition you could play around with the attribute values and see what you need to change to make QF-Test not recognize it anymore or even recognize a wrong component in the GUI. You will find that you need to change quite a few attributes before QF-Test recognizes a different component. This means that component recognition with QF-Test is very robust. With regression tests a significant part of the GUI component criteria need to change before QF-Test will not recognize the component anymore even if the component has no name or id.

When you click the 'Component' node QF-Test will highlight the recognized component in the GUI by outlining it with a dark blue border.

  • Action Delete the CalculatedPrice from the 'Name' attribute. Because as long as there is an entry in the 'Name' attribute QF-Test will not consider the attributes below.
  • In the 'Extra features' table, set the state of the extra feature with the name id from Should match to Ignore back to Final price.
  • Change the 'Feature' attribute from Final price to xxx.
  • Click the TextField node and check QF-Test still highlights the Final Price field in the GUI.
  • Change the 'Feature' attribute back to CalculatedPrice, either via the respective toolbar button or by typing [Ctrl-Z].
  • Change the qfs:label value in the 'Extra features' table from Final price to Accessories Price.
  • Click the 'TextField' node and check QF-Test still highlights the Final Price field in the GUI.
  • Change the qfs:label value in the 'Extra features' table back to Final price.
  • Change all Structure and 'Geometry' attributes to a different value and check that QF-Test still highlights the Final Price field in the GUI.
  • Delete the 'Feature' attribute and change the qfs:label value in the 'Extra features' table from CalculatedPrice to Accessories Price.
  • Check that now QF-Test highlights the Accessories Price field.

This is just to give you a bit of a feeling for component recognition. In the above mentioned chapters (and some more) of the manual you will find detailed information about what to do when you have trouble with component recognition.