Intake
TestArchitect scans application windows for their controls during both the identification and playback phases of testing, to establish the controls’ TA classes, TA properties and TA property values. This is called the intake process.Different factors can contribute to different results being obtained for some properties of a control at different stages in development and testing. Hence, it is important to understand how the intake process works.
Generally, when developing your test, you use the Interface Viewer or Identify tool to create your interface definitions. During this process, for each given window or dialog box, TestArchitect performs an intake of the controls, which involves scanning the controls, reading their properties, and thus deriving the TA classes and TA properties for them. You then select which of those controls, and which of their TA properties, to capture for your interface definition.
Because an interface definition generally does not reference the native properties of the UI elements of an application window, the intake process must be repeated during testing, prior to any attempt at interfacing. Without that, your interface definitions, with their references to TA classes and TA properties, would have no meaning. So, for instance, before your test attempts to interact with the controls of, say, the Car Rental-Login window, TestArchitect must scan the window (assuming it is present), and again establish the TA classes and TA property-value pairs of each control, which it stores in a memory cache.
Intake for a given window’s controls can occur at various times during a test. In most cases, it takes place only once, upon the first attempt to interface with the window. So, for example, say your test encounters the following action lines for logging into the application under test:
Upon seeing the reference on line 15 to a window argument with a value of car login, TestArchitect goes out and grabs the interface entity with that name:
The automation then establishes which open window is being referenced (the one with the title=Car Rental-Login property-value pair), and examines its cache to see whether it has already performed an intake of that window’s controls. If not, it then performs the intake.
intake action
Under some circumstances, you may wish to force a refresh of TestArchitect’s cache of a given window’s controls during the test. This may occur when some action has been taken which is expected to modify the controls present in the window, or modify their properties (such as making a control visible). You can perform this refresh with TestArchitect’s built-in action, intake.
Intake behavior
While some windows and dialog boxes have only a few controls, others may hold quite a large number of controls. Hence, performing an intake of all the controls of a window can take a considerable amount of time. Test performance can take a hit, especially if intakes are performed on several control-intensive windows, or re-performed on the same window multiple times. For that reason, plus the fact that not all controls of a window always need to be interfaced with, TestArchitect’s default behavior is to limit the number of controls it processes during an intake. It does this by two means:
- Ignoring invisible controls. In this context, invisible controls are those for which one or both of the following are true:
- the visible TA property = false
- the width and height properties are both equal to or less than zero.
- Ignoring container class control contents. Some controls, such as those of class Treeview and Table, can contain a potentially large number of child controls. In many cases, a test may have no need to access such child controls. Hence the default behavior of TestArchitect during an intake is to regard any container class control as “locked”; TestArchitect will capture the container control itself, but skips over its contents.
Overcoming default intake behavior
invisible controls: During testing, if you have a need to interface with controls that are invisible (as per the above definition of invisible), TestArchitect provides the built-in setting load invisible controls. Note that load invisible controls is a setting, not an action, so it has no immediate effect. Its default value is no. By setting it to yes, the next time an intake needs to be performed on a given window, the window’s invisible controls are included in the intake. Moreover, with this setting switched from no to yes, TestArchitect understands that any set of window controls already in its intake cache is outdated, hence for each given window a new intake is performed the next time an action line attempts to access a control in that window.
container class controls: As mentioned, TestArchitect’s default behavior is to bypass the intake of controls that belong to container class controls. There are times, however, when your test does need access to such child controls. During test creation, when you capture controls via the Interface Viewer or Identify function, you can unlock any container class in order to gain access to the contents of any control of that class. (Note that you don’t unlock individual controls; you unlock all controls of a given container class, though only within the confines of a given window.) Unlocking one or more container classes of a window and then saving to an interface entity causes an interface entity setting to be written to the interface definition:
At runtime, during an intake on this window, this setting instructs TestArchitect to go ahead and retrieve all the child controls of the specified container classes. (For more on container classes, see Container classes.)
Tel:
Email: