|User Guide / Interface definitions|
To illustrate the problem, consider the table-like control known, in WPF, as a datagrid. In WinForms, the datagrid equivalent is called a datagridview, and in Telerik it's a radGridView. Hence, in test automation, identifying UI controls by their raw classes is an unwieldy and unappealing proposition.
TestArchitect's solution, TA classes, is a standardized set of control types, each of which TestArchitect recognizes and knows how to interact with.
Along with these built-in classes, TestArchitect provides a number of built-in mappings. Familiar platform-specific controls are mapped to their corresponding TA classes automatically.
Note, however, that this set of built-in mappings cannot cover all of the possible control types that might appear in the immense diversity of AUTs and their platforms. For example, a custom control may look and behave exactly like a table, yet have a native class name that is unknown to TestArchitect. Without a little intervention on someone's part, TestArchitect does not know how to handle it properly. In such a case, you can provide that help by manually mapping this unknown control to a known TA class – in this case, table. Once so mapped, the full range of built-in actions that work on the TA class table are available to interact with the new custom control.