Just since a while I am making my test automation scripts in Quick Test Pro. After working and dreaming in WinRunners TSL for six years, this was quite a change. Things that were easy in WinRunner, became not that easy in QTP, but the use of classes and objects made things better.
Down here some issues I had to cope with.
No incrementation shortcut
As obvious as hell, I cannot get used to the lack of ++, --,+=, -= and other short ways to increment, multiply etc. Nothing else to do then pointlessly call i = i + 1 on an (expensive) single line of code.
No 'continue' in loops
Within WinRunner, I used 'continue' just as often as the 'break' command. There is no substitute in QTP for this command, so you have to think out your flow properly, because you can only exit a loop (by 'exit {looptype}') and not start from the beginning from anywhere within the loop.
No fall-through in 'select case' flow
This becomes more and more a "drawback" list of QTP, but the thing I miss is the fall through mechanism of switch/case or select/case. Of course it is called Visual Basic, and starters will often forget a 'break;' statement at the end of a case, but the C like switch is very powerful at the moment you get used to it.
One time function evaluation in QTP
This one is less obvious, but important for WinRunner users. In WinRunner you could write code like this:
while (obj_exists(myObj) != E_OK)
web_refresh(myFrame);
Each time the while loop is entered and looped, the obj_exists() function will be called and evaluated. Within QTP a function that is called as part of the initiation of the loop will only be evaluated once. In this case the loop will never be exited when the object is not available the first time the loop is entered.
All functions in an if statement will be handled in QTP
In C like languages, if statements are lazy. An example:
if (set_window(myWin, 1) == E_OK && obj_exists(myObj, 10) == E_OK) { ...
WinRunner would evaluate the first function (the setting of the window) and when this results in an error, the other function in the if statement is skipped because of the AND: the if statement can never evaluate to TRUE anymore, so processing the other evaluation makes no sense.
Visual Basic like languages like QTP don't bother this kind of logic. In such kind of construct, QTP will evaluate both functions, no matter the outcome.
1 comment:
those pitfalls will be wildly useful to us soon -- but for the moment, i'm just trying to navigate the transition from 8.0 to 9.2!
i have a script that uses the 'continue' statement as part of error-handling functions. it worked great in 8.0.
in 9.2, however, i'm getting an error that i can not use the continue statement inside the function because it is not, at the point of declaration, in the context of a loop!
at this point, all i can think of is writing a bunch of conditionals and making them every other line inside my loop, but that's a terrible solution.
do you have any ideas on how to recreate the 'continue' statement?
Thanks!
nema [at] epicsys [dot] com
Post a Comment