AUT -bound modules
This category contains keywords that you have created to perform specific actions in your AUT . The AUT -bound modules category is split up into further categories, representing the dialogs and windows of your AUT . A typical structure for the AUT -bound modules category might look like this:
In each category, the Test Cases that execute actions in this area are stored. In the Main Window category, keywords to open dialogs from the menu or the toolbar could be stored. In the Main Window - General Tab category, you would find the keyword to select the security tab, to save the changes in the security tab etc.
The AUT -bound modules are all linked to the AUT in some meaningful way. For example, they could contain one or more of the following:
Structuring the AUT -bound modules in this way (5.1) makes it easy to navigate through the keywords you have created.
Unbound modules
The unbound modules category contains modules which do not fit into the AUT -bound modules category. Good candidates for the unbound modules are utility modules, as mentioned in the previous section 5.1.1.3. Other unbound modules could be sequences of actions that other AUT's could also use. Unbound modules generally contain no data or component names specific to one AUT . They may, however, contain default data you expect to use throughout your tests (like the operator, the pre-ascend in trees etc). At some point, the unbound modules could be moved into an external Project to serve as a library Project for more than one AUT 3.8.8.
The unbound module category (5.1) can be structured in categories according to actions or components.
![]() |
Think about how many ''layers'' you need in your hierarchy - sometimes it is well worth making an unbound module, sometimes an unbound module would add an unnecessary extra layer. If your unbound module is not significantly different from the ub_Test Case from the library Project , it is probably superfluous. |