 |  |  |  |  |  |  |  |
| Version 8.0.1 |
Though they often go unnoticed,
at least until the first ComponentNotFoundException occurs,
the 'Component' nodes are the heart of a test suite,
since stable component recognition is the central challenge of a good GUI testing tool.
QF-Test takes care of it most of the time,
but some special situations require manual definitions or interventions.
Thus it is important to understand components and their handling in QF-Test and
this chapter aims to explain the fundamentals.
The video 'Component
recognition' first explains the criteria for component recognition, then (starting at min
13:07) the use of generic components using regular expressions, followed by generic components using variables
in component recognition attributes.
There are two videos available explaining in detail how to deal with a
ComponentNotFoundException:
The video 'Dealing with the explosion of complexity in web test automation' gives you a good idea of how QF-Test handles a deeply nested DOM structure.
Live recording of the special webinar 'Component recognition'.
Actions by the end-user of an application are transformed into events by QF-Test. Every event has a target component. For a mouse click this is the component under the mouse cursor, for a key press it is the component that has keyboard focus. When an event is recorded by QF-Test, additional information about the target component is recorded as well, so that the event can later be replayed for the same component.
Component recognition is one of the most complex part of QF-Test. The reason is the need to allow for some degree of change. QF-Test is a tool designed for regression testing, so when a new version of the SUT is tested, tests should continue to run, ideally unchanged. So when the GUI of the SUT changes, QF-Test needs to adapt. If, for example, the "OK" and "Cancel" buttons were moved from the bottom of the detail view to its top, QF-Test would still be able to replay events for these buttons correctly. The extent to which QF-Test is able to adapt depends on the available recognition criteria. In this area software developers often can, with relatively low effort, make a great contribution to the creation of robust regression tests.
The following criteria are available for component recognition:
These criteria figure into recognition with varying importance. Especially important are a component's class and Component identifiers. With the latter, developers can make a great contribution to test stability (see How to achieve robust component recognition). For more information, see Weighting of recognition features for recorded components.
Windows-TestsFor native Windows applkations please also refer to section 15.5.
Information about recognition can be stored by QF-Test either in a 'Component' node or directly in the event nodes as a SmartID. In 'Component' nodes versus SmartID you will learn which option is preferrable for which use case.
By default, QF-Test will record 'Component' nodes.
There are some components that QF-Test addresses relative to a parent component. Among these are table cells, list entries, tree nodes, button icons, or a checkbox inside a table cell.
QF-Test has special ways of addressing these components. This topic is explained in detail in Sub-items: Addressing relative to a parent component.
Also, QF-Test offers the ability to define Scope to limit actions (clicks, text entry, checks) to components contained within.
| | | | | | | Last update: 9/10/2024 Copyright © 1999-2024 Quality First Software GmbH |
