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.

Putting my cards on the table, I argue for DP and this is mainly because it allows you to utilize varying identification methods with object properties. Here I’ll talk a little about what that means from a code perspective, but also try to show where the OR fits in relation to this.

Let’s imagine some hypothetical items from a web application as they would be defined in the OR method:

Here the first two objects (SwfWindow) are using the Text property of the window. The edit field (SwfEdit) and the generic object (SwfObject) are using the Name property of the respective fields. None of that is very obvious from that code, however. Further, those properties I just mentioned are the only way that those objects will be recognized.

Notice also that in the second line I have two window objects, both of which are named “Account Locate”. That can obviously leave room for ambiguity. The way QTP keeps them separate is based on their position within the object tree. QTP “knows” that a window called “Account Locate” has a child object, another window, also called “Account Locate”. What that covers up is that there often is a difference between objects besides their place in an object hierarchy. Perhaps one window object has a Name property called ‘AccountLocateMain’ while the second window object has a Name property of ‘AccountLocateView’. In this case, given that the Name property differs, it would perhaps be a better choice to use than the default Text property, which offers no such distinction.

Now let’s see those same two objects in DP mode:

So what you should get out of this so far is that with DP the properties for objects are written with their corresponding property description. OR, on the other hand, shows only a logical description of the object. And that logical description, as you’ve also seen, may not be enough to uniquely identify the object. Even if that logical description is enough from QTP’s point of view, it’s not necessarily clear from a programmatic standpoint.

A key point here is that properties define object descriptions. The “descriptive” part of “Descriptive Programming” means that you add as many properties as you need in order to uniquely identify an object.

So that means you should always just use DP, right? Well, there are considerations to be aware of.

The main thing to realize is that you must create the object hierarchy yourself. With DP, QTP will not really help you. Contrast that with OR, where you record objects and then QTP creates the hierarchy for you and stores it in the object repository (which you can view quite easily with the Object Spy). On the other hand, to some people, manipulating an OR hierarchy is time-consuming and error-prone while doing the same for a DP hierarchy is considered less so. Personally, I find both approaches time-consuming and error-prone but I find that the DP approach forces me to think about things a bit more. You definitely do have to be more careful when coding with the DP approach. Why is that?

Well, OR, which QTP tracks track of, allows for auto-complete when scripting. That can be really nice. The reason this works is because QTP has a full list of what is associated with what and thus can help you when typing out object strings. DP does not have auto-complete because it’s all done manually with object descriptions that you create programmatically. QTP has no idea what is associated with what until you type it — and even then, it’s pretty much just taking your word for it until run-time execution.

Yet even though you don’t have the built-in child object referencing of the OR, DP allows you to use the ChildObjects functionality of QTP to programmatically determine what children exist for what given objects and what properties exist for those children. Consider that hierarchy above for the Account Locate window and you can see why that might come in handy. This is even more handy when you consider that the children might change given what your test scripts do or don’t do. This functionality is tied in with the notion of “description objects” that you can put to use with but DP which you cannot with OR. I’ll come back to this in a bit.

You might also want to consider performance in terms of the time it takes to run a full test suite. On average, DP will be somewhat slower than OR. With DP, QTP creates an object from the provided hierarchy of provided logic and locates the object in the application before performing an event (such as click) with that object. If you had an application with the objects I mentioned, you could try this logic:

I got this simple idea from Descriptive Programming (DP) vs Object Repository (OR). You’ll see that the OR version tends to work a little faster. On the flip side of that, however, when the Object Repository gets quite large due to the number of objects it is storing, that has been known to decrease the performance of QTP while it is in the process of recognizing an object during test execution. So the performance issue cuts both ways.

In truth, the actual size of the Object Repository is not necessarily what determines performance. It’s the type and number of objects that QTP has to deal with at a given time from within the OR. For any objects that could be ambiguous — and thus appear as identical objects — QTP must allocate additional properties to recognize the object uniquely. If you have a lot of this going on in your application, then this is when performance can suffer.

Some people will point out that objects have logical names in OR (which is true) and then argue that this makes it easier to identify them (which doesn’t have to be true). DP, on the other hand, doesn’t have the concept of a “logical name,” per se, since it’s based on principles of programmatic construction of objects. Some will point out that one of the problems with the “logical name” approach is when OR seemingly recognizes more than one object as having the same logical name. Then you end up with things like SwfButton_1, SwfButton_2, and so on: all referring to the same object but recognized, for whatever reason, differently each time QTP went through a test. Sometimes you’ll see the opposite, which is where you have one object (say, SwfButton_1) that gets recognized as two or more objects.

Code written with DP can be easily copied into other scripts or utilized modularly within function libraries, such as by passing a DP object description string. This is because DP-based scripts are self-contained. With OR-based scripts, a simple copy will not give you a working script because there is a dependency in that the scripts need to be associated with the repository (or repositories) that contain the object definitions. All the repositories (local and shared) would have to be associated with the test to make it executable. Obviously this is not much of a burden if you use Shared Repositories since that is, after all, the entire point of such a repository: sharing reusable components among multiple scripts. With that, however, you do have to keep in mind that changes to a shared object repository have the potential to affect many tests.

OR-based scripts do have a nice advantage in that if you need to change objects, you can simply change the object definition in one place (i.e., the Object Repository) and have all scripts that use that Object Repository immediately reference the changed object. With a DP approach, since all of your objects are programmatically created, that means those objects will have to be manually updated. In situations where there are several changes in the application interface, OR-based approaches can be a quicker maintenance effort due to this. That being said, this isn’t so much an argument against DP as it is an argument that with DP you have to figure out how you want to structure your object descriptions in a maintainable way and decide how you want to modularize your logic by making sure your DP object descriptions are passed along from a single source, rather than being redefined in numerous places.

All of this is really a series of trade-off and/or compromise type statements. There are a few black-and-white’s, however. It’s most definitely the case that certain things are only possible with OR. For example, a Bitmap CheckPoint is not possible with DP. It can only be done if your object is present in your OR. On the other hand, you can only reliably use description objects with a DP approach. QTP does have technology called “Smart Identification” and this will not work in DP, only in OR.

This brings up a good question: What’s Smart Identification? When the recorded definition for an object does not enable QTP to identify an option from the OR, QTP uses a “smart” algorithm to identify a likely object. It’s sort of like a disambiguation mechanism. Objects that are dynamic or inconsistent in their properties are those most likely to fail recognition.

My personal take is that anytime my automated testing tool has to be guessing what object it should use, I’ve introduced a bit of unreliability into my framework. So, for me, the fact that I can’t use Smart Identification with DP is one of the strengths of the approach.

Given this trade off approach, most people at some point will try to get the best of both worlds. So, you may be asking: can I use both DP and OR? The answer is yes, up to a point. If you are going to do this, you can start an object description with OR and move to DP along the way. You cannot start with DP and move to OR. So I can do this:

Here I went from an identifier in OR to an object description in DP. That works because QTP can use that OR identifier if there is anything that matches the object description as a child of that OR-based reference. I could not, however, do this:

The reasons for this should be fairly obvious: if you start with DP, then QTP has no way to tie the remaining OR-based objects to anything since you haven’t started at the parent of the object tree. I personally haven’t found many reasons to combine a DP and an OR approach, at least in terms of building the use of such a combination into my QTP test frameworks.

One really cool thing you can do with DP is get object collections and I mentioned this before earlier when I briefly talked about object descriptions. More specifically, you can grab all the objects on the screen that match a certain identification. This is where the idea of a description object comes in. For example, you may have a series of radio buttons. You can define a description object that will get the collection of all radio buttons on the screen. You can then do things with all of those radio buttons, such as verify their text labels, or click each one of the radio buttons (perhaps verifying that some are mutually exclusive).. You can also use run time properties to select a certain radio button out of the collection. What’s also nice is that when a new radio button is added to the same screen, the object collection will automatically pick it up. I’m not going to cover all of how to do that in this post, but just know that this is possible with DP and it’s not something you can do with OR.

The upshot is that you should decide on your overall design principles regarding your automated test logic in QTP and then decide which of the two approaches, DP or OR, you want to use. I personally go for the DP approach because I find it widens my options when writing test frameworks or test harnesses in QTP and it forces me to be a better automated test programmer by not relying on QTP doing a lot of work for me. For an example of someone who thinks the DR is helpful but should not be used to the exclusion of the OR, check out Descriptive Programming Versus Object Repository In QTP.

Keep in mind that opinions differ and there probably isn’t a “right way.” Much like the Windows vs. Mac OS “wars”, you will find people engage in endless (and usually fruitless) debates about whether DP or OR is “better.” In truth, they are both effective mechanisms in QTP to allow you to execute automated tests. The onus is on you to figure out which approach makes the most sense for how you plan to structure your automated test writing and test execution.