Ignorance or negligence may cause test developers to add “problematic” object names to the test scripts. For example:
Object names that contain the “IMPORTANT - Avoid “occurrence” property in object names” property. (The property value may be unstable, and if so, contribute to reduced test case stability.)
Object names which are basically IMPORTANT - Avoid large number of object names due to object hierarchy duplication of already existing object names, and which identify “the same” object, but with some differences in text properties of the object name, such as
caption, etc. (In case of top level containers and similar, thus can cause all names of child objects of the container to be duplicated under the new name, which is a redundancy that may cause problems due to enlarging the object map, potentially causing maintenance and performance problems and confusion for the script developers.)
With the script based object map introduced in Squish 6.3 it has become very easy to inspect the object names (real names) within test script code itself, to perform any kind of checks on them before “increasing” the damage (of using the problematic object names in more and more script code).
The following example implementation checks for the use of “occurrence” properties in object names, as well as for top level object names which have not been “whitelisted” explicitly, and reports each occurrence in the test results, along with a few tips on how the user should proceed.
In this particular case the test script execution is also aborted, to force the user to act on this, rather than ignore the problem.
In case of Python, the checks are being performed upon importing the names.py module, which contains the object names by default. (However, the checks can be added to any other module, of course.)
Example Sanity Check Report¶
Test Results view after execution of the test case, while having problematic object names in
The details for the object names failing the “occurrence” sanity check:
The details for the object names failing the “only expected top levels” sanity check:
Adding the object map sanity check example implementation to an existing or new test suite is very easy, as shown below.
Once added, one needs to go through the reported problems and resolve them as desired.
object_map_sanity_check.py(in a top level folder of
Global Scriptsor in the
Test Suite Resourcesunder
names.py with added call to sanity check module: