|User Guide / Interface definitions|
Container classes are classes of UI controls that can contain other controls. Because the number of child controls that a container holds is potentially unlimited, such container classes present possible performance hits during test runs. To avoid such issues, TestArchitect offers the option of bypassing the recognition of container child controls.
Ideally, during an interface intake for a window, a test automation system should scan and analyze all of the of UI controls belonging to the window, including all child controls belonging to a list or hierarchy, no matter how long or deep it is. However, this approach may cause serious performance issues when it comes to controls that carry a heavy load of data. Such classes of controls, which include Treeview, Listbox, Listview and Table, are referred to as container classes. As a practical matter, TestArchitect's default behavior is to treat container class controls as locked when it encounters them during the interface scanning processes, bypassing any processing of their child elements.
That works out great if you don't need your test to interact with any child elements of a given container control. But sometimes you do, and for that, you do need to have them defined and mapped. For example, a table control may have a cell which contains multiple check boxes, and you may want to have your test click one of those check boxes. With TestArchitect's container class unlocking feature, you can choose which container class you want to unlock in a given window, and then freely interact with the child elements of controls of that class.
This locking of container controls, and the option of unlocking them, applies both to the offline interface definition process (that is, during intakes performed by the Interface Viewer), as well as during the test process.