TestComplete considers process, windows and controls as objects. When executing a test command over them, it first checks whether the object exists in the system and then executes the needed method or property of this object. The test engine posts this message to the test log when it fails to obtain a reference to the object that you specified in your test. The message indicates that something has changed in the tested application and its state differs from the state it had during test recording or creating.
1. Explore the test log
-
Find the first error message in the test log. Depending on the command being executed, TestComplete may post several error messages to the log. This happens due to certain specifics of the test and script engines functioning (the script engine is used even when you run keyword tests, not scripts). Typically, the first error message corresponds to the problematic command and further errors are caused by this first error. These instructions assume that the first error message is the “Cannot obtain the window...” error.
-
To better understand what test command was executed when the error occurred, double-click the error message in the test log. TestComplete will open your test for editing and automatically highlight the line that was executing when the error occurred.
2. Explore the tested application
Check whether the desired object exists in the tested application. For instance, developers could change the tested application and remove the tested window or control from it. This change could cause the error in your test.
If the tested object exists in the application, explore its properties, find the cause of the problem and fix it. For information on possible causes and solutions, see below.
-
The tested application must be running and have the same state it had when the error occurred. If the application was closed after the test run, you can start it again and pause the run on the problematic test line. To do this:
-
Set a breakpoint on the problematic line in the script test or keyword test operation. To find that line or operation quickly, double-click the error message in the test log. TestComplete will switch to the test editor and highlight the line or operation that caused the error. To set the breakpoint, click the editor’s gutter next to the line or operation, or press F9.
-
Run your test. The test engine will automatically pause the test run when it reaches the breakpoint.
-
Examine your application and check whether the desired object exists. For instance, developers could change the tested application and remove the tested form or button from it. This change could cause an error in your test.
See instructions for web tests running in remote environments
See instructions for web tests running in remote environments
See instructions for web tests running in remote environmentsIn cross-platform web tests running in remote environments, the test engine cannot access web applications from your local TestComplete instance. As a workaround, you can do any of the following:
Run and explore your tested application on your local computer.
– or –
Manually check whether the problematic object that matches the specified search expression actually exists on the page. You can do it, for example, by examining the source code of the tested web page. To get the source code, you can use the following expression:
Sys.Browser().Page("*").contentDocument.Script.eval("document.documentElement.outerHTML")
You can post the source code to the test log or view it in the Evaluate dialog or the Watch List panel:
Tip: To get the source code of an individual web element, you can use the following expression:
Sys.Browser().Page("*").FindElement(".container-wrap").outerHTML
See instructions for desktop, mobile tests, and web tests that run on your local computer
See instructions for desktop, mobile tests, and web tests that run on your local computerSee instructions for desktop, mobile tests, and web tests that run on your local computer
-
In TestComplete, select 
Display Object Spy from the Tools toolbar. This will open the Object Spy.
-
Use the Object Spy to select the needed object on the screen:
-
You typically select a window or control by dragging the target icon (
) to it. See how it works.
-
If you need to select a hint, menu item or another popup object, use the 
“Point and fix” mode. See how it works.
After you select the object, the Object Spy will display its properties.
If the object does not exist in the application, re-record your test or update its commands to match the tested application.
If the object exists, then, to find the cause of the error, explore properties of the problematic object:
-
In TestComplete, select Display Object Spy from the Tools toolbar. This will open the Object Spy.
-
Use the Object Spy to select the needed object on the screen:
-
You typically select a window or control by dragging the target icon () to it. See how it works.
-
If you need to select a hint, menu item or another popup object, use the “Point and fix” mode. See how it works.
After you select the object, the Object Spy will display its properties.
Below are typical causes of the problem and typical ways to eliminate them.
The window class name, caption or index is misprinted.
The window class name, caption or index is misprinted.The window class name, caption or index is misprinted.Check if you typed the class name, caption and index correctly.
The window caption (text), class name or index has changed.
The window caption (text), class name or index has changed.The window caption (text), class name or index has changed.To recognize windows, in general case TestComplete uses three attributes: window class name, caption and index (see Naming Windows). If any of these attributes does not match the expected values, TestComplete fails to find the window during the test run.
To solve the problem, change the test or update the test commands so that they use the appropriate values for window recognition. Below are some tips:
-
If the window class name or caption change during the test run or change from one test run to another, use the ? and *wildcards in place of variable parts. ? stands for any single character, * - for an arbitrary string. For instance, if developers changed the class name from TComboBox to TComboBoxEx, you can use the string TComboBox* that will match both values. This will make your test more resistant to changes in the tested application.
-
If the class name and caption identify the window uniquely, do not use the index in the window name. This will make your test more resistant to changes in the tested application.
-
It is recommended to map the window (or control) name and use an alias to access the window or control. Name mapping lets you use other window properties to recognize the window (or control). This will make your tests more resistant to changes that occur in the tested application. See Name Mapping for more information.
The object’s position in the object tree was changed.
The object’s position in the object tree was changed.The object’s position in the object tree was changed.One of possible reasons is that the tested object resides on another level of the object tree than it did during test creation or recording. This happens if developers changed the tested application and added or removed some forms or controls. A typical example of this situation is when developers added a panel between the form and the missed button or when they remove the substrate panel between the form and the tested control.
If the object hierarchy has changed, then the general solution is to change your test or tests in order for them to match the new hierarchy.
We recommend that you map the tested object’s name and use an alias to address the object from your tests. If the object is mapped, TestComplete searches for it using a set of object properties. Also, it can do this on different levels of the object hierarchy. All these features make your test more reliable to changes in the tested application. For more information on mapping, see Name Mapping.
One more way to make your tests change-proof is to use specific scripting functions that search for the desired test object by object properties. If the search is successful, the functions return the found object. You can insert these functions’ calls into your test and work with the test objects returned by these functions. For more information, see Searching for Objects in Tests.
The object has not been created by the time TestComplete tries to obtain it.
The object has not been created by the time TestComplete tries to obtain it.The object has not been created by the time TestComplete tries to obtain it.If the recognition settings are correct and the object is located on the expected level of object hierarchy, then perhaps the object had not been created by the time the test engine addressed it. To solve the problem, modify your test so that it “waits” for the object. The way you do this depends on the test type you use. For detailed information, see Waiting for Process or Window Activation.
The tested application stopped responding.
The tested application stopped responding.The tested application stopped responding.If the tested application has stopped responding to user actions and operating system’s messages, TestComplete is unable to find the required window or control. You can check whether the application is frozen in the Windows Task Manager. To display it, right-click an empty space in the operating system’s taskbar and select Task Manager from the context menu. In the Task Manager, switch to the Applications tabbed page and find the needed application on this page. If the application is frozen, the Status column will display Not Responding.
According to the Freeze Diagnostics properties of your test project, the test engine may automatically terminate an application if it stopped responding. If the test engine terminated the application, you will see the error message “The process does not respond. It will be terminated.” in the test log. In addition, TestComplete will automatically generate a detailed error report that will help you find the cause of the issue faster. For more information on how to view and change the Freeze Diagnostics properties, see Diagnosing Application Freezes.
The object tree model differs from the model that was used to create the test.
The object tree model differs from the model that was used to create the test.The object tree model differs from the model that was used to create the test.
-
For desktop applications
TestComplete supports two object tree models: Tree and Flat. Tests created for one of these models are not compatible with the other model. The Flat model was the default one in TestComplete 3 and earlier. Since TestComplete 4, the default tree model is Tree. If you run tests created for the Flat model, you may need to check which of the models is active. To do this:
-
Switch to the Project Explorer (you can do this by selecting View > Project Explorer from the TestComplete main menu).
-
Right-click your project in the Project Explorer and select Edit > Properties from the context menu. This will open the project editor and activate its Properties page.
-
Select General from the tree of property groups in the left part of the page. Check the value of the Object tree model setting on the right.
-
For web pages
If you are testing a web page, you may need to check the tree model which TestComplete uses for web objects (see Web Tree Models). To do this:
-
Switch to the Project Explorer (you can do this by selecting View > Project Explorer from the TestComplete main menu).
-
Right-click your project in the Project Explorer and select Edit > Properties from the context menu. This will open the project editor and activate its Properties page.
-
Select Open Applications > Web Testing from the tree of property groups in the left part of the page. Check the value of the Tree model setting on the right. The model must be the same as the model you used when creating the test.
