Curious QTP behaviour when using on error: Proceed to Next Step

Because we build our own framework, the on error settings in QTP are default on "Proceed to Next Step" for our unattended continuous script. So when a test is scheduled in the middle of the night, the test won't stall on errors like a function with an argument too few or many, an array that is out of bounds or an accidentally undeclared variable (please build an undeclared variable checker HP, the Patterson boys could do it years ago, you can do it too!).

It works fine most of the time, although debugging is done with an "attended run" script and all possible error detection on: Popup Messagebox and Option Explicit everywhere.

The curious behaviour happened in an Select Case. Consider this code:

Option Explicit
Dim myCondition : myCondition = 2
Select Case myCondition
    Case 1 MsgBox "Wooh! Condition 1"
    Case 2 MsgBox "Displaying undeclared variable: " & undeclaredVariable
    Case 3 MsgBox "Meh, Condition 3"
End Select 

When you run this code in attended mode, you'll get a nice error nagging about the undeclared variable.
However, when you run this in unattended mode, you'll get a messagebox with the text: "Meh, condition 3"

QTP is doing what it says: Continue with the next step. But the step is not fulfilling the Select condition and program technical a major sin!
Because I ran this accidentally in unattended mode, it took me some while to get a finger behind the error. In the end, I learned to always debug in attended mode.

QTP pitfalls for WinRunner users (Part II)

Today was another day of fiddling around with QTP. The VBScript language of QTP is still a bit new to me and I stumbled into some neatly disguised traps:

1. The .exist(n) method is in seconds
Normally I use the .exist() method for synchronization, but today I used it for checking if the right finalise page was reached or that I had to cope with an data validation error somewhere. I do not bother test objects, because at this moment I am not testing, but just doing an automated data entry project with some complex datamodels. (This is where the classes are hopping in I mentioned before).
To test my code, I started my QTP script and went for my lunch. When I got back, only one set of data was entered and the screen was synchronizing on a page. And synchronizing. And synchronizing.

After pressing the stop button and debugging my code, I found out that the wait time in exist(n) is expected in seconds, while the help file mentions milliseconds!
My script was waiting for a never appearing page for 10.000 seconds instead of 10.000 milliseconds.
Not very uncommon for the WinRunner user by the way (obj_exists() and win_exists() works almost the same), only misleading because of incorrect information the help file.

2. Location is optional in object identification
When there are multiple object in your AUT that match the same description in the object repository, QTP just picks the first one when the ordinal properties are set to 'none'.
And this property is always set to none whenever you learned the object while it was unique on the screen.
In WinRunner, you used to get the error message E_NOT_UNIQUE, but QTP is figuring it out all by itself, even with Smart Identification switched off. Something to keep in mind.

3. Eval() is not exactly eval();
Eval() in QTP is used for comparison, while Execute() is used for assignment:

a = 2
msgbox eval("a = 2") ' displays 'True'
msgbox a ' displays '2'
msgbox execute("a = 3") ' displays nothing, a is set to 3
msgbox a ' displays '3'

Keep this in mind if you used the eval() function in WinRunner for assignment of virtual variables. It won't work in QTP and you have to use execute().

4. There is no fast way to export the object repository to plain text
Unlike WinRunner, where the GUI map was just a plain text file, it is not possible to easily export (and manipulate) the object repository. It is possible though, but you'll have to do it through COM automation on the QTP application. I tried it today, but I failed miserably because I could not access the ActiveX object (probably not enough authorization on my workstation).
However, if I get it working, I will post the code on Automated Chaos.

WinRunner to QTP transition: Pitfalls to avoid (part I)

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.