Overview¶
Some user wish for a mechanism in Squish that automatically exercises their application to bring it into all possible states and to capture all GUI objects and add entries for them to the object map.
This is a commonly asked question and this article aims to explain why this is rarely a good idea.
Problem #1 - Object name reuse vs. large number of object map entries¶
Squish reuses already existing entries in the object map to avoid create (mostly redundant) object names. This is important because otherwise new, redundant object names would be added to the object map (when recording or copying object names in the picker/debugger), which would lead to an extremely large amount of redundant object map entries, which in turn badly hurts maintenance of the object map. (After all, the point of the object map is to avoid object name redundancy in the test scripts.)
Bad effects in object map maintenance not considered, having a large object map requires Squish to check each and every object name in the object map whether it already identifies the currently considered object (while geenrating object names, for example when recording or copying object names in the picker/debugger). This can severely hurt recording performance.
Problem #2 - Objects created at runtime, NOT at start of application¶
In many applications objects are created at runtime. This means that it is impossible to get a "list" of "all" objects from the application at a single point in time. Instead, all GUI elements would have to be "exercised" to be able to assemble such a list of "all objects of the application", and if external factors may lead to further application state changes and thus object creation, those would have to be considered too.
Problem #3 - Majority of objects are irrelevant for automation¶
Depending on the GUI design only a small fraction of all objects are relevant for automation, 3% and less is actually very realistic. So adding all the unneeded object names would again negatively affect performance, despite the fact that they are extremely unlikely to be used for any automation scenario.
Problem #4 - Countless possible AUT states¶
Even with a moderate GUI there might be thousands or millions of possible AUTs states, and it is impossible for Squish to know which effect a click on button X has, or a checkbox being checked, therefore it is practically impossible for Squish to automatically exercise an application to cover all possible AUT states.
Problem #5 - Duplicate object hierarchies¶
It is not possible for Squish to reliable recognize object hierarchies duplication (see IMPORTANT - Adjust object names for objects with changeable texts early ). This means that while exercising an application automatically the AUT could keep changing its state (perhaps it shows the current time in the window title?), resulting in countless possible AUT states, although "in reality" these are just duplicates.
Pragmatic solution - Interact with all desired objects in a dummy recording¶
To quickly add a batch of (or all) desired objects one can perform a dummy recording in which one clicks on all desired objects. After ending the recording, the recorded script can be discarded, but Squish will have generated and added object names for the objects to the object map then.