This topic describes No matching UI error that you might encounter during automation, its common causes and possible solutions.
Error Handling Behaviors
· No matching UI is a fatal error and the test run will be aborted immediately. This can save time in investigating failures.
· TA also displays the specified timeout of the corresponding timing built-in setting.
• If in INITIAL, such as, logging in app fails, the test is aborted (see the picure below).
• This happens for both manual aborting and using exit test module defined in on error/on error action.
Problem:
During automation playback or in test results, you might encounter the following error message:
No window found matching <interface_entity> within the timeout of <value> seconds. Please check the interface definition for <interface_entity>, or set a longer timeout with the "window wait" setting."
Common causes
· AUT change issue, that is, title of the window is changed.
· Timing issue, that is, the window is not available within a specified timeout, defined in the window wait built-in setting.
· Script issue, that is, improper interface, or improper definition/invalid syntax of dynamic identifier.
Possible solutions
· If the AUT is open, check whether the title of the window is changed.
o In the Viewer, if the window is unmatched, see the Property Comparison panel (learn more) to understand why the window is no longer matched. You might need to recapture the interface definition of the window.
o In the Viewer, if the window is matched, it might be timing or script issue. You might need to modify your test procedures.
§ Use Screenshot Recording (learn more): You have an instant view of the state of the system at each critical juncture, and instantly know if that state was as expected.
§ Adjust higher wait time value of the window wait built-in setting.
§ Verify whether the correct interface is currently used.
· If the AUT is not available within a given timeout, it might be timing issue. Try adjusting higher wait time value of the window wait built-in setting.
No Matching Control
During automation playback or in test results, you might encounter the following error message:
No matching UI object found for <interface_element> within the timeout of <value> seconds. Please check the interface definition for <interface_entity>, or set a longer timeout with the "object wait" setting.
Common causes:
· AUT change, that is, previously-captured TA properties are changed, or the control no longer exists.
· Timing issue, that is, the control is not available within a specified timeout, defined in the object wait built-in setting.
· Script issue, that is, improper definition/invalid syntax of dynamic identifier.
Possible solutions:
· If the AUT is open, check whether the previously-captured TA properties of the control are changed.
o In the Viewer, if the control is unmatched, see the Property Comparison panel (learn more) to understand why the control is no longer matched. You might need to recapture new TA property/value.
o In the Viewer, if the control is still matched, it might be timing or script issue. You might need to modify your test procedures.
§ Use Screenshot Recording (learn more): You have an instant view of the state of the system at each critical juncture, and instantly know if that state was as expected.
§ Adjust higher wait time value of the object wait built-in setting.
· If the control is no available within the specified timeout, it might be timing issue. Adjust higher wait time value of the object wait built-in setting.
· It is suggested that after updating the test procedures, you double-check the control’s existence by using the check control exists built-in action.
Error Handling and Recovery
TestArchitect has a number of mechanisms to support error handling to allow for tests to continue to run after encountering unexpected difficulties. Situations resulting in errors may stem from unanticipated problems experienced by the system under test, or from the automation itself. (Learn more)
Timing Handling
· Successful testing requires that the automation correctly handle the varying response times of a system under test, and not to attempt to continue with interactions before the system is finished with the previous function. (Learn more.)
· Conversely, it is also important that we wait no longer than is necessary for a function to complete, as excessive waits could potentially slow down overall run times of larger test runs.
· The behavior of built-in actions in TestArchitect is governed by a number of built-in settings. (Learn more.)
· The following table summarizes the built-in settings:
|
Setting |
Description |
|
The maximum time to wait for a control to become available. |
|
|
The maximum wait time for an HTML page to load completely. |
|
|
The maximum wait time for a window to become available. If a control on a window is addressedTestArchitect looks for that window. If the window is not yet visible, TestArchitect waits until either the window is available or the maximum time specified by this setting is exhausted. |
|
|
The maximum wait time for property value of a control or window to be available. |
|
|
How long to wait for a window in case of only three following actions: if window exists, if window not exists and does window exist. If the maximum time specified by this setting is reached, the result is false. |
|
|
How long to wait for a control in case of only three following actions: if control exists, if control not exists and does control exist. If the maximum time specified by this setting is reached, the result is false. |
|
|
The maximum wait time for an item to become available. Items affected can be tree nodes, menu items, list/combo box items or table cells. |
|
|
The maximum wait time for a value of a get or check action to be changed. |