TL;DR: Using plain script language variables over the standard file simplifies refactoring and maintenance at the expense of losing the ability to generate (or reuse) the names when recording.

NOTE: Throughout this blog article, we will use the JavaScript language for code samples. Everything shown here can be expressed in any of the programming languages shipped by Squish though, usually with only minor syntactic changes.

Object Names

To reference controls in a user interface, Squish uses so-called ‘multi property names’ in test scripts. Such names are basically strings using a dictionary-like notation to express a set of constraints which any matching object has to satisfy. For instance, the name

{type='Button' text='OK'}
matches the first found object for which the type property has the value Button and the text property has the value OK. Object names can also be nested to express relationships between objects. For instance, the name

{container={type'Dialog' text='New Document'} type='Button' text='OK'}
would match the first object with the type property Button and the text property OK which is contained (hence the container constraint) in an object whose type is Dialog and the text is New Document. This naming scheme has proven to be very powerful and is successfully used by Squish customers. It provides a number of useful benefits:

The naming scheme is entirely independent on the visual rendering of the control, i.e. the screen resolution or X/Y coordinates do not matter.
It’s also possible to use wildcards (or even regular expressions) in object names.
The object names are generated automatically as tests are recorded.
The set of properties used for generated object names is highly configurable to satisfy the automation requirements on a vast range of applications (e.g. translated user interfaces).

Using this naming scheme which is both expressive but also robust is an important tool to ensure that test scripts are easy to maintain even if the application changes (e.g. buttons get reordered). Hence, it is no surprised that object names are ubiquitous in Squish test scripts.

Duplication Impedes Maintainability

However, the widespread use of object names also tends to introduce some problems. Consider an object name which might be used to click on the File menu item in a menu bar, e.g.

{container={type='MenuBar'} type='MenuItem' text='File'}
It’s not hard to imagine that this object name is used in various of the test script code, e.g. when creating a new file, or when opening an existing file, or when exiting the application via File->Quit. So there are multiple places with script code like

mouseClick(waitForObject("{container={type='MenuBar'} type='MenuItem' text='File'}"));
The risk imposed by this duplication of the object name in multiple places manifests as a problem in case you need to change the object name. For instance, it may be that the requirement is brought up that the tests should still run even if the application under test is executed with a different language such that all text labels in the user interface are shown in e.g. German. In that case, the text property of the menu item would no longer be called File but rather Datei. Instead, you could use some internal identifier (maybe called itemId or such) which has a value which is not dependant on the user interface language.

Since the object name of the menu item is repeated in multiple locations, it’s necessary to update all occurrences of the name to not use the text property anymore. This includes the risk of missing some occurrence of the object name.

Object Maps Avoid Duplication

Squish mitigates this issue by including the notion of an Object Map. The idea is that instead of using actual object names in the script code, a free-form ‘symbolic name’ is used instead. When executing the test, Squish translates the ‘symbolic name’ into an actual object name by performing a lookup in the object map, which is a simple table of two columns mapping each symbolic name to an object name.

By default, the object map is implemented as a plain tab-separated text file called This file is stored in the test suite directory (suite_…). Symbolic names in this object map are free-form strings with the only requirement that they start with a colon (‘:’). Hence, in the script code you typically see statements like

And the file then contains

:File_MenuItem  {container={type='MenuBar'} type='MenuItem' text='File'}
This implementation is elegant both in it’s functionality as well as it’s simplicity:

The functionality of the file is easy to understand, there is no ‘hidden magic’.
The file is stored as a plain text file which makes it viable to store it in revision control systems (Subversion, Git etc.) and view textual differences between two version of the file.
The file format is simple enough to process the file with separate (possibly hand-written) tools, i.e. it’s easy to generate the file automatically or parse it for further analysis.

Squish also provides an Object Map API to access the text file programmatically.

By avoiding the need to duplicate object names, the file is very effective at simplifying test code maintenance.

Continue reading at Improved Management Of Object Names | froglogic blog