Improved Management Of Object Names – Part 2

In a previous blog entry, we introduced an alternative, script-based, approach to maintaining a mapping of symbolic names (variables) to the actual object names (strings). By using script variables instead of free-form strings, the mapping was no longer stored in a separate text file but instead it was brought into the domain of the programming language, thus enabling a lot of tooling support e.g. for renaming symbolic names or finding references of a symbolic name in the test code.

However, there are still some annoyances related to managing object names like this, most notably caused by the fact that the actual object names are still plain strings:

Object Names As Strings Cause Trouble

  1. Composing object names is awkward and error-prone. For instance, assume that there are two object names for an imaginary Add User dialog and an OK button in the objectsmap.js file we introduced in the previous blog article:
    addUserDialog    = "{type='Dialog' text='Add User'}"
    okButton         = "{type='Button' text='OK'}"

    Since there can be multiple OK button objects visible at the same time, you might want to introduce a dedicated object name which specifically references the OK button in the Add User dialog by using the special container constraint. You might do:

    addUserOKButton  = "{container={" + addUserDialog + "} type='Button' text='OK'}"

    …i.e. use plain string concatenation. However – notice the mistake we made? The addUserDialog variable has a value which is already enclosed in curly braces, so we don’t need to (in fact: must not) specify them again when using the variable. So what we actually should have done is:

    addUserOKButton  = "{container=" + addUserDialog + " type='Button' text='OK'}"
  2. Implementing parametrised object names is fragile. To implement ‘parametrised symbolic names’ (which a programming language usually calls ‘functions’ or ‘procedures’ or ‘subroutines’) you could define a function such as
    def dialogName(title):
        return "{type='Dialog' text='" + title + "'}"

    This works well for many invocations such as dialogName(“Add User”) to generate the object name {type=’Dialog’ text=’Add User’}, but there’s a bug in here: what if the title contains a single quote character, e.g. for a dialog which is shown when a file could not be written to disk as in:

    cannotWriteFileDialog = dialogName("Can't Write File");
    // OOPS: cannotWriteFileDialog is set to {type='Dialog' text='Can't Write File'}

    This generates an invalid object name, causing an error at runtime.

  3. Both of these issues are only detected so late (when actually using the object name) because the object names are plain strings. Had we used some more expressive data structure, standard tools such as syntax checkers of ‘lint’-style programs might have detected the issue before we even ran the test.

Improved Management Of Object Names

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.

Squish tip of the week: How to modify the WaitForObject timeout

Troubleshooting a script can be long and exhausting especially if there are objects which can not be found. Fortunately, we can adjust the timeout duration for waitForObject to save us some time.

By default the duration of waitForObject is 20000 milliseconds (20 seconds), which looks like this:


During the given time Squish will check if the object can be located, is visible and enabled. If this is the case, the script continues otherwise returns an error and stops.

Squish 6.1 Beta with Visual Verification Points

About ten months after the release of Squish 6.0, we are proud and excited to make available a BETA of Squish 6.1 to you.

The main new features of this release is an innovative approach to visual verifications; convenient application window and screen control as well as general improvements to Squish.

You can read the full announcement at

We are looking forward to your feedback which we happily accept at

Squish tip of the week: How to Automate a Modern UI Windows Store App

Did you know that Squish supports automating Modern UI/Windows Store apps (also called Metro applications) when used on the Windows desktop*?

If an application offers information about its GUI objects via UI Automation, it is possible to automate the application with Squish and the supported Microsoft’s UI Automation API.

How to inspect an Application or GUI Control for UI Automation Support

With the Microsoft Inspect tool (direct download) it is possible to check whether an application (or a particular GUI control in an application) exposes/supports UI Automation.

Squish tip of the week: How to look up Windows control class names

When a window is created, an application defines a window class, which is registered with the system. This class defines various properties of the window like the window title, background color, cursor and the window class name itself.

But how to get a Windows control class name?

Class names of Windows controls can be looked up with tools like Spy++ or AU3_Spy.

froglogic enters partnership with E.S.L. to expand into Israel

Hamburg, Germany (2016-06-14)

E.S.L. and froglogic GmbH today announced a strategic partnership to distribute and support froglogic’s Squish GUI Tester and Squish Coco products in the market of Israel. E.S.L. will promote and resell Squish GUI Tester and Squish Coco in Israel and provide local, technical support services to their customers.

Squish GUI Tester is the market leading, functional test automation tool for cross-platform and cross-device GUI testing on desktop, embedded, mobile platforms and web browsers.

Squish Coco is the professional, cross-platform C, C++, C# and Tcl code coverage analysis tool. Both tools are used in more than 3,500 QA and development organizations around the world.


Squish tip of the week: Show View Action

Squish provides various views which are not shown all the time to unclutter and tidy up the Squish interface. However, sometimes specific views are needed. So how do you access them?

The easiest way is the so-called “Show View action” which is useful to open a view that isn’t already open.

One way to open a new view is by clicking Window > Show View and to choose from the listed submenu. If the wanted view is not visible, click the “Other…” option to pop up the Show View dialog.

Bug Location and Patch Analysis with Squish Coco 3.4

Hamburg, Germany June 7, 2016
Squish Coco 3.4 Release

froglogic is excited to announce version 3.4 of Squish Coco, its multi-platform C, C++, C# and Tcl code coverage analysis tool.

Besides several smaller improvements, this new release of Squish Coco features two innovative, new features to help developers use code coverage data to analyze the impact of source code patches and find potential bug locations in the source code:

  • Extended Patch Analysis.
    With this feature, a source code patch can be analyzed to find out which tests have covered the modified code. The analysis identifies the impact areas of the changes and the associated vulnerabilities. This extends the Squish Coco 3.3 pre-commit patch analysis feature, which analyzed the impact of a patch only before it was committed.
  • Bug Location.
    This feature allows computing, based on coverage data, a list of source code lines which are most likely responsible for a failure in the test suite and therefore likely are the location of buggy source code.
  • Two More Report Modes.
    The HTML coverage report now has a new tree display mode for functions and for source files, in addition to the existing modes. The tree display makes navigation easier especially in large projects.

The release notes of Squish Coco 3.4 can be found at

To evaluate Squish Coco 3.4, please visit Evaluate Squish Coco.