Assume you have some data that tells your scripts how to function when they run a particular set of actions. Instead of this logic being stored in a test script, common action sets are stored off in a data source. In this case, I’ll use Excel but you can use any data source at all. One thing I’ve found fairly effective in terms of an approach here is to create a class that contains the methods for building a dictionary that will essentially bring in the “action sets.” Here an action set refers to the data plus the test actions to take with that data against the application.

One of the nice things about SilkTest was the use of a dereference operator. I was disappointed to see that QTP didn’t have that. Yet I found you could start to mimic some of the functionality with the Eval function and the Execute statement.

A problem with VBScript is that it doesn’t allow you to have optional parameters in your procedures. This also means you can’t do function overloading. There are various ways to deal with this but many of them can lead to a maintenance problem and require you to change how your new (“extended”) procedures are called. Ideally, you don’t want to have to change how the function is called each time you extend it. So let’s look at a few ideas here.

A lot of testers use QTP as a record-and-playback tool first and then add some logic to start building a framework around whatever their test scripts are. That’s an approach that can work but those same testers often don’t utilize one of the key strengths of QTP, which is it’s object-oriented structure.

Rather than treat it as obvious that using classes is a good idea and without giving a tutorial to object-oriented programming here, I plan to showcase some specifics to keep in mind when using a class-based approach in QTP as well as give a specific example of how this approach can be useful by showing how you can encapsulate your logic for better maintainability.

In a previous post, I talked about how I prefer the choice of descriptive programming in terms of my QTP logic for recognizing objects. Descriptive Programming (DP) is a specific approach that QTP makes possible for constructing your recognition strings programmatically. Anyone who has had to modify SilkTest frame files or create XPath-based locators for Selenium will quickly realize that “descriptive programming” is really just a name that QTP has given to what many tools already make possible. In fact, it’s the Object Repository (OR) — the alternative approach in QTP — that tends to be a value-add of QTP beyond other tools, at least for some people.

In any event, my previous post was a little skimpy on specific details so here I’ll look at a specific example of modularizing some test logic using the descriptive approach in QTP.

QTP allows you to use what the tool calls Descriptive Programming (DP) as a way to write your automated test logic. This is really nothing more than a way of referencing objects, similar to the recognition method path (object strings) in Rational Robot, the GUI map strings of WinRunner, the tags and locators in SilkTest, or the selectors in Selenium. This style of object recognition is often put in opposition to another form that QTP allows you to do, which is store strings in the Object Repository (OR).

So which one should you use: DP or OR? Does it really make a difference? Are there advantages to one over the other? Can you use both? Should you? I’ll talk about all this a little here.