Detecting Problematic Object Names Automatically

Not all object names are equal. Some are “less good” than others, for various reasons. To avoid proceeding to use problematic object names, it can be useful to make the test script developers aware of them automatically, as early as possible.

In our Knowledge Base article Example – Custom Object Map Sanity Checks we demonstrate how this problem could be solved. Below you will find some additional information for the solution presented in the Knowledge Base article.

Squish Object Names

To understand how such automatic checks can be implemented in Squish, some background information on object names in Squish is required:

Squish identifies GUI objects (that it should interact with) by object names. These object names are stored in the so-called Object Map.

Since Squish 6.3, the Object Map is a script file (in the same scripting language as the test suite it belongs to), and the object names are variables defined in this script file.

The values of these (object name) variables are dictionaries in which the keys are the names of the properties of the desired GUI object. And their values represent the values of each respective property of the desired GUI object. This Python example from a simple object name file demonstrates this:

address_Book_MainWindow = {"type": "MainWindow", "unnamed": 1, "visible": 1, "windowTitle": "Address Book"}

Here the (only) object name is “address_Book_MainWindow”, and it identifies an object of type “MainWindow” which, among others, has a property “windowTitle” with the value “Address Book”.

Reporting Possible Problems

To implement checks for the object names, it is required to iterate over these object names, get their values and then perform the desired checks on these object names. Once that has been done, it is time to consider how the problems should be reported to the user.

Here is an example that shows how reporting the problems could look like in the Test Results view, directly after executing the test case/suite:

The first section contains details about the object names that unexpectedly contain the “occurrence” property:

The second section contains details about unexpected top-level object names:

To Force or Not to Force

When using such checks, one must consider whether simply to report the problems upon test case/suite execution, or to abort script execution.

For existing test suites it may be difficult to fix all object name problems in one step. In such cases opting for merely reporting the problem could make sense. And yet, the warnings in the Test Results would make it difficult to ignore the problems in the long run.

Example Implementation

An example implementation of the above mentioned two types of checks can be found in the article Example – Custom Object Map Sanity Checks in our Knowledge Base (kb.froglogic.com).

The post Detecting Problematic Object Names Automatically appeared first on froglogic.