Components
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.
- Videos
-
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'.
- GUI actions and components
-
Actions by the end-user on the Components of a GUI 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.
- Recognition
-
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:
- Class, correlates with the component's function
- Name, based on the Component identifiers
- Feature, a piece of text belonging to the component
- Extra features, further recognition features like a description or tooltip
- Index
- Geometry
- Component hierarchy
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.
- Storing recognition information
-
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.
- Child elements and nested components
-
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.
