Question

Suppose I use QTPs recovery scenario manager to set the playback synchronization timeout to 0. The handler would return with “continue with next statement”.

I’d do that to make sure that any following playback statements don’t waste their time waiting for the next non-existing/non-matching step before failing:

I have a lot of GUI tests that kind of get stuck because let’s say if 10 controls are missing, their (consecutive) playback steps produce 10 timeout waits before failing. If the playback timeout is 30 seconds, I loose 10×30 seconds=5 minutes execution time while it really would be sufficient to wait for 30 seconds ONCE (because the app does not change anymore — we waited a full timeout period already).

Now if I have 100 test cases (=action iterations), this possibly happens 100 times, wasting 500 minutes of my test exec time window.

That’s why I come up with the idea of a recovery scenario function setting the timeout to 0 after/upon the first failed playback step. This would accelerate the speed while skipping the rightly-FAILED step, yet would not compromise the precision/reliability of identifying the next matching GUI context (which creates a PASSED step).

Then of course upon the next passed playback step, I would want to restore the original timeout value. How could I do that? This is my question.

One cannot define a recovery scenario function that is called for PASSED steps.

I am currently thinking about setting a method function for Reporter.ReportEvent, and “sniffing” for PASSED log entries there. I’d install that method function in the scenario recovery function which sets timeout to 0. Then, when the “sniffer” function senses a ReportEvent call with PASSED status during one of the following playback steps, I’d reset everything (i.e. restore the original timeout, and uninstall the method function). (I am 99% sure, however, that .Click and .Set methods do not call ReportEvent to write their result status…so this option might probably not work.)

Better ideas? This really bugs me.

Answer 1

It sounds to me like you tests aren’t designed correctly, if you fail to find an object why do you continue?

One possible (non recovery scenario) solution would be to use RegisterUserFunc to override the methods you are using in order to do an obj.Exist(0) before running the required method.

Function MyClick(obj)
    If obj.Exist(1) Then
        obj.Click        
    Else
        Reporter.ReportEvent micFail, "Click failed, no object", "Object does not exist"
    End If
End Function

RegisterUserFunc "Link", "Click", "MyClick"
RegisterUserFunc "WebButton", "Click", "MyClick"
''# etc