Check Out the Latest News About SmartBear Connect

Recovery from unexpected windows when waiting for action

Status: New Idea
by abinash11 on ‎06-19-2017 08:32 AM

Currently, (as per TestComplete help)

 

TestComplete only checks for unexpected windows when the script performs an action (Click, DblClick, Activate, etc.). The check does not happen when the script performs certain operations with window properties or when it executes a function, for example, WaitWindow.

 

This is a crucial functionality in increasing the robustness of the tests particularly when the AUT is not stable. But since the 'OnUnexpectedwindow' only works when an action is performed, it is not suitable in many situations, especially while waiting. There should be some way to handle this better in a straightforward way.

Comments
by
on ‎06-19-2017 07:31 PM

without performing an action , how dose TC knows window is unexpected or expected?

for example you may be waiting to popup a window or just waiting

In first instance it's not unexpected second it's expected.... 

by abinash11
on ‎06-20-2017 05:54 AM

We will define the Unexpected window contents inside the 'OnUnexpectedwindow' definition. For example, if you wait to save a large file in a network and it is not accessible for some reason, then you may get a popup stating that the path is not accessible. The properties of this window can be defined and the action can be triggered from the 'OnUnexpectedwindow' function. But it will not get triggered unless there is the next 'Click' or 'DoubleClick' event. If this unexpected popup hides the control to be clicked, then the script will return error instead of handling the event.

by Community Hero tristaanogre
on ‎06-20-2017 06:04 AM

In this case, it's not exactly an "unexpected window".  You are expecting the possibility that the path is not accessible and, therefore, should include in your automation conditional code to handle the situation.  "Unexpected Window" in the definition of TestComplete is exactly that... that the window or form that is displayed is completely unexpected and you have no way of planning for it.  So, the event is intended to allow you to build a generic handler to deal with the situation.  Optimally, once such an event is triggered and you see it in the log, you go back to your test automation and build in the aforementioned conditional code to handle the situation... to bullet proof your automation code.

 

In the situation where you are "waiting" for something else to happen and a pop-up comes up, you could build in to your "waiting" code a timer object to check every few seconds for a pop-up window and to handle it then.  Again, if you know the possibility is there that such a thing could occur, it's not "unexpected"... it is expected but with a lower probability.  So, you build your code "expecting" it to happen so you can deal with it.  Just good programming.

by abinash11
on ‎06-20-2017 06:25 AM

What I mean is that other tools offer things like Recovery Scenario Manager etc. where you can define such scenarios separately (without including all such external situations into your code in each case) and attach it to the scripts when needed. If such a popup is displayed, the recovery scenarios defined will kick in and close the popup. The actual script need not handle it.

 

This approach can help in defining all the unexpected scenarios separately without making your script code more and more complex. If there are 10 such scenarios that can happen over the duration of a script, then you don't have to repeat this in each script or in each function. 

TestCompelte does not have a Recovery scenario handler separately as far as I know. When I say 'Unexpected', it means that the popup does not occur in a 'normal' case but there is a possibility that it will be shown and we can define the recovery to push the 'Close' button etc.

by Community Hero tristaanogre
on ‎06-20-2017 06:32 AM

In that case, right your own "recovery scenarios" as separate modular script code functions or keyword tests that handle the situations you need to handle... this is not different than what I already described.  For example, one recovery scenario is "path not found".  Build a generic piece of code that will execute your recovery scenario for "path not found" instance and then incorporate that into any test case that has the potential for doing so.  Even in what you described, you still need to build out the recovery scenario handler...  TestComplete doesn't have a feature per se called "recovery scenario" but it has the ability and flexibility for you to add any such code to any test case in a modularized fashion.  Again, what you are describing are not "unexpected windows" by TestComplete's definition.. they are "expected possible scenarios" that you need to code for.  Just a matter of doing the code for them.

by Community Hero tristaanogre
on ‎06-20-2017 06:33 AM

Obviously, you're used to QTP/UFT... this is a different tool with a different architecture.  What you are asking is possible to do with TestComplete as is, just a matter of doing it.

Top Kudoed Authors