Dealing with "Object '....' not found" script errors

Last edited on

Symptoms

Synchronization functions like waitForObject() or action functions like mouseClick() error out with a script error like this:

Object '<name>' not found.

Here, is the argument passed to the function. The error may seem to occur randomly or it might always occur in a particular script statement.

In a Nutshell

Keep in mind that when you use object synchronization with wait functions such as waitForObject() and waitForObjectItem(), these functions have built-in a default timeout of 20000 milliseconds (20 seconds). But if your test machines are under heavy (and more or less random) load that is sufficient to slow down your application, it may be that this default timeout becomes insufficient for some operations.

So, if you know that after pressing a button the next object that should be automated will take 15 seconds to appear (maybe because the application must do a computationally expensive calculation), then setting a timeout larger than even the default 20 seconds is a good idea.

Before:

clickButton(waitForObject(":DoIt_Button"));
// "DoIt" takes roughly 15 seconds...
clickButton(waitForObject(":Close Results_Button")); // Default 20sec timeout

After:

clickButton(waitForObject(":DoIt_Button"));
// "DoIt" takes roughly 15 seconds...
// So allow Squish to wait for up to 30 seconds for the next object:
clickButton(waitForObject(":Close Results_Button", 30000)); // 30sec timeout

Possible causes

Before interacting with a GUI object Squish must first find the object. This typically involves Squish looking up the object’s symbolic name in the Object Map to find the properties by which the object can be identified, and then Squish will search the AUT’s objects to find one that matches the properties. Then Squish will check to see if the object is ready for interaction, i.e., that the object is both visible and enabled. If Squish can’t find the object (i.e., if it cannot find any object whose properties match those it is looking for), or if it finds the object but the object isn’t visible or isn’t enabled, a catch-able exception will be thrown.

The underlying causes typically fall into two categories:

Other differences (which are not addressed here) are changes to the application’s source code or configuration such as changed label texts, changed window titles, or changed version number (e.g., as shown in the About box).

Possible solutions

Identify timing problems

First, determine whether the error is caused by a timing issue or not. Is the error thrown by a call to a function like waitForObject() or waitForObjectItem() that times out after 20 seconds? If you are sure that it is legitimate to wait longer (for example, waiting for your application’s splash screen to go away so that the main window is revealed), you can specify a longer timeout. For example:

waitForObject("....", 60000); // 60 seconds

Is the error thrown by an interaction function like mouseClick()? If the function is given an object name or reference directly, there are various options to try. If the object is the subject of a waitForObject() or similar call on the preceding line, you could add an explicit timeout to make the wait longer. And if there is no such call, you could try adding one, either before the interaction function, or within it, e.g., change from something like mouseClick(":_OK_Button") to something like mouseClick(waitForObject(":_OK_Button")).

A quick and dirty way to detect (and work around) timing issues is to force Squish to wait for a specific hard-coded amount of time. For example, here is a statement that will make the script execution wait for 5 seconds:

snooze(5); // 5 seconds

In some cases, this alone will be sufficient to resolve any problems. However, in general it is best to to use a wait function wherever possible.

Coping with state differences

How to cope with state differences depends on what causes the differences.

If the problem is with a “Save and Restore” feature it might be possible to switch it off. Alternatively, make sure that just before the end of every test recording, you close files and generally set the application to how you want it to be at the start of each test and then close the application and finish the test recording. A more drastic approach is to delete the application’s settings before each test run so it always starts up cleanly.

If the test involves modifying a file that will then be read by the application on a subsequent test, make sure that the original file is preserved and used for each test run.

A counter-measure to prevent changing text properties (i.e., labels that show the current date and time or random IDs) from causing test runs to fail, is to use inexact property matching for the affected objects using Squish’s wildcard and regular expression matching facilities. (See Improving Object Identification and Matching Objects with Changeable Texts

Understanding Squish object not found error messages

No object of specified type found

When Squish cannot find any object of the type specified in the real name (also see How Squish looks up Real Names from Symbolic Names), it will give an error message similar to this, which mentions the “type”:

LookupError: Object '{type='QMainWindow'}' not found. Could not match properties:
    *type* for object name: '{type='QMainWindow'}'

Object(s) found but property differences exist

When Squish finds one or more objects of the type specified in the real name (also see How Squish looks up Real Names from Symbolic Names), but one or more of the property value specified in the real name does not match any of the found objects, it will give an error message similar to this, which mentions each unmatched property:

LookupError: Object '{type='QMainWindow' name='x'}' not found. Could not match properties:
    name for object name: '{name='x' type='QWidget'}'

Related Information