|User Guide / Interface definitions|
Interface mapping identifies elements of an interface in an application under test
A test automation tool must, by its nature, interact with the user interface (UI) of the application under test. But UI elements – that is, the windows, menu items, HTML buttons, etc. of the AUT – don't always remain constant. From one application version to the next, a UI element's name, or position, or any other property that the test automation tool may rely on to find it, may change. Hence direct references to windows and controls within tests can easily end up breaking the test. For example, if a button labeled OK is renamed Submit, any hard-coded references to a button with label property = "OK", suddenly break.
To avoid the errors and maintenance headaches that such changes can bring, TestArchitect projects employ interface definitions, more simply known as interfaces. Interfaces form a layer that sits between the test and the AUT, insulating the test from AUT changes.
Interfaces are assigned to projects just as test modules and actions are,
and reside on a branch of the TestArchitect explorer tree:
A TestArchitect interface consists of a set of modules known as interface entities that include information on windows and controls and how to identify them. These definitions allow you to assign logical names, or TA names, to both the windows and the controls within them. (Note that, for the purposes of this discussion, references to windows and controls apply equally to web pages and HTML elements, respectively.)
To sum up TestArchitect's interfacing structure: A TestArchitect project contains one Interfaces node, which can house one or multiple interfaces. (Typically, a separate interface might be created for each application in the project.) Each interface, in turn, might have multiple interface entities, each of which would represent a single window, dialog box, or web page. And each interface entity would typically have multiple interface elements, each mapped to a specific control or HTML element.
The following figure illustrates the role of interface definitions in a test, one which simply writes a name into a user name field of a login window. Since a project may include more than one interface, the first line establishes that the Car Rental interface is the one to be used.
The Car Rental interface contains several interface entities. (Three
are displayed in the figure, though only one is used by the test). Each maps a TA name to
a window of the AUT. The enter action of the second action line calls up
the interface entity with TA name of login which, as depicted, is
assigned to the window Car Rental-Login. This interface entity
contains a number of interface elements, each of which represents a control – such as a
label, textbox, or button – on the AUT's login window. The control which the
enter action must access is the one with TA name = user
name. As shown, this TA name is mapped to the upper textbox control in the
Car Rental-Login window.