Handling the 'Cannot Obtain the Android Control...' Error

TestComplete considers Android processes 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 the test recording or creation.

1. 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.

2. 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 will automatically highlight the line that was being executed when the error occurred.

3. Check whether the desired control exists in the tested application. For instance, developers could change the tested application and remove the control from it. This change could cause the error in your test.

4. 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.

In order for you to be able to explore the object, the tested application must be running. If the application was terminated after the test is over, run it again and pause the run on the problematic test line. To do this:

• Set a breakpoint on the line that was executed when the error occurred.

  If you have not opened the test for editing yet: double-click the error message in the test log. TestComplete will open your test for editing and highlight the line that was executed when the error occurred.

  To set the breakpoint, simply click the editor’s gutter next to the line, or press F9. After the breakpoint was set, the line will be highlighted in red.

• Run your test. The test engine will automatically pause the test execution when it reaches the breakpoint.

For more information on breakpoints and debugging, see Debugging Tests.

Now, you can explore the application under test:

• Open the Mobile Screen window. To do this, click Show Mobile Screen on the TestComplete Test Engine toolbar.

• Select Display Object Spy from the Tools toolbar. This will invoke the Object Spy window.

• Use the Object Spy window to select the desired object in the Mobile Screen window. To do this, drag the target glyph () to that object. While dragging, TestComplete will highlight objects under the mouse cursor with the red frame. Release the mouse button when the cursor is over the desired control, and TestComplete highlights this control with the red frame. The Object Spy window will display the object’s properties.

  Alternatively, you can pick an object in another way: click in the Object Spy window and perform the actions needed to display the desired control. When the object is visible, hover the mouse over it in the Mobile Screen window and press Shift+Ctrl+A to “fix” the object (the shortcut can be changed in TestComplete options). The Object Spy window will display the object’s properties.

• Click Highlight Object in Object Tree. This will select the object in the TestComplete Object Browser panel.

Below are typical causes of the problem and typical ways to eliminate them.

The control’s identifier, class name, text or index is misprinted.

The control’s identifier, class name, text or index is misprinted.The control’s identifier, class name, text or index is misprinted.

You can address controls of Android Open Applications by controls’ identifier and index, or by class name, text and index (see Addressing Objects in Android Open Applications (Legacy)).

Make sure that you typed all the components of the test object name correctly.
 

The control’s identifier, class name, text or index has changed.

The control’s identifier, class name, text or index has changed.The control’s identifier, class name, text or index has changed.

To recognize controls in Android Open Applications, TestComplete uses either the control’s identifier and index, or the control’s class name, text and index (see Addressing Objects in Android Open Applications (Legacy)). 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:

• Index and text are two components that change rather frequently. Where possible, it is recommended using the “identifier + index” combination rather than the “class name + text + index” combination.

  Also, it is recommended skipping the index where possible.

• If the control’s text changes during the test run, use the ? and *wildcards instead of variable parts. ? stands for any single character, * - for an arbitrary string.

• It is recommended mapping the control name and using an alias to access the control. Name mapping lets you use other properties to recognize the control. This will make your tests more resistant to changes that occur in the tested application. See Name Mapping for more information.
   

The control’s position in the object tree was changed.

The control’s position in the object tree was changed.The control’s position in the object tree was changed.

One of possible reasons is that the control resides on another level of the object tree than it did during the test creation or recording. This happens if developers changed the tested application and added, or removed, or replaced some controls. A typical example of this situation is when developers added (or removed) a substrate Layout control to some form.

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 an Object.
 

The control has not been created by the time TestComplete tries to obtain it.

The control has not been created by the time TestComplete tries to obtain it.The control has not been created by the time TestComplete tries to obtain it.

If the recognition settings are correct and the control is located on the expected level of the object hierarchy, then, perhaps, the control 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 control. The way you do this depends on the test type you use. For detailed information, see Waiting for Objects in Android Open Applications (Legacy).