Preface

As covered in a previous paper, TestComplete offers robust support for the traditional technique of data-driven testing (DDT). DDT is a powerful and flexible approach to extending test cases and deserves treatment in several papers in its own right. In addition to support for DDT, TestComplete offers a new technique called Object-Driven Testing (ODT). This paper will serve to:

• Introduce the concepts of ODT.
• Introduce the ODT user interface in TestComplete.
• Give an overview of TestComplete’s support for ODT.
• Examine the ODT sample included with the TestComplete installation.

Introducing Object-Driven Testing

Object-driven testing is a concept that was designed for TestComplete with two primary goals in mind: 1, to provide a visual interface to ease the difficulties associated with data management in data-driven testing scenarios. And 2, to enable users of TestComplete to take advantage of some of the benefits of object-oriented development within their testing projects.

If you’re using comma-separated text files for your external data storage in a DDT test project, you may have noticed that, while the flexibility is great, managing the data can become convoluted. You can often end up with files like the following:

02,c,”John”,”Q”,”Public”,13,”Product 02”,”1234 Anywhere St.”,”San Antonio”,”TX”
04,b,”Jane”,,”Doe”,13,”Product 01”,”10 My Lane”,”Metropolis”,”KS”
05,c,”Walter”,,”Johnson”,26,”Product 02”,”101 Pitching Legend Ln.”,”Washington D.C.”,

With hundreds of such lines of data, understanding and managing this can become quite a chore. Alleviating this chore is exactly why the ODT object and ODT panel were designed — to provide a visual interface which eases the difficulties associated with data management in DDT scenarios. With ODT, instead of text files with the lines of data shown above, you’d see things like figure 1.

 

Figure 1 – DDT data management in the ODT panel.

The second goal of ODT has to do with making the advantages of object-oriented development available to users of TestComplete. A discussion of object-oriented development (OOD) and theory goes beyond this paper, but for now, it’s enough to know that in OOD, we can create objects that own data and know what to do with that data. Object-driven testing gives you the same capabilities, and in a visual interface as well!

We’ll go into more detail on this subject in this paper and in others, but for now, our introduction is served by explaining that, in the venerable customer/orders example, we can create a customer testing class that owns data about a customer, and that knows how to enter that data and validate the response of a database.

Some will begin doing this work and ask the age-old question: why go to all this trouble to write all this code to simply add a customer record, when we could do it much more quickly without the classes? While there are several advantages to using ODT, the most obvious and the one with considerable return-on-investment is that of maintenance. Making liberal use of testing classes makes our testing projects far more flexible and less prone to breakage. A good example is this: I have a class that is essentially a menu-clicking object. If I give it the name of a menu item, it can find the menu item and click it when I tell it to. In a large testing project, I may well end up with hundreds of menu clicks. Without the testing class, I’d have hundreds of places where script code finds a menu item and clicks it; with the testing class, I have that code in one place. Earlier this year, I started using a different component set for my application menus and toolbars. When I made that change, every one of my test projects broke – the menu objects had changed. Rather than having to fix the problem hundreds of times, I was able to simply change the menu testing class in one place, and suddenly all my test projects began working again. Maintainability. It’s not the only reason for ODT, but it’s a very, very good one.

Introducing the ODT Panel in TestComplete

In object oriented development, you will encounter the concepts of classes and objects; classes being definitions and objects being instances of those definitions. There is a similar arrangement of classes and objects within the ODT panel in TestComplete.

In figure 2, you can see that within the drop-down list of the ODT panel there are two sections: Classes and Data.

 

Figure 2 – the ODT panel drop-down.

The Classes section should be obvious; this is where you can create and define test classes. The Data section, on the other hand, is where you can visually create objects, arrays, etc. and populate them with data. When the classes section of the drop-down is selected, the class definition parts of the panel are active (figures 3 and 4).

 

Figure 3 – defining object properties.
 

 

Figure 4 – defining object methods.

With the Properties and Methods tabs of the ODT panel, you’re able to define a testing class much like you would a class in a traditional object-oriented language. For more information on the process of creating testing classes in the ODT panel, see the TestComplete online help.

In the Data section of the ODT panel, you are able to instantiate testing objects, enter data and otherwise visually manage your object-driven tests. As you can see in figure 5, objects can be created in a nested manner, allowing objects to own arrays of other objects. A good example would be the ubiquitous customer object owning multiple order objects.

 

Figure 5 – the ODT panel’s Data section.

A simple overview of the ODT panel controls reveals the following:

 

Figure 6 – the ODT panel toolbar.

In figure 6, you can see the various controls on the ODT toolbar. We’ve already discussed the drop-down. The New Class and New Data Group buttons are rather straightforward: they create new items in the Classes or Data sections, respectively. The New Property button and New Method button are mutually exclusive; you’ll only see one or the other at one time. Also, they’re contextual; if you’re defining a class, clicking these buttons will have an effect on the current class. However, if you’re working on an object in the Data section, clicking these buttons will add a property or method only to the current object, rather than to all objects of that class. See the help file for more information on this.

TestComplete's Support for Object-Driven Testing

TestComplete’s object-driven testing model is possibly too powerful. As you’ve already seen, the capabilities are available visually, via the ODT panel, but they can also be accessed programmatically. By using the ODT scripting object, you have access to both the Classes and Data sections of the information in the ODT panel; you can create new classes or edit existing ones. You can set properties, call methods and create instances of test classes all from within your test scripts.

With TestComplete’s programmatic support for ODT, it’s possible to combine the visual and scripting sides of ODT within one project. Many customers will have their technically savvy users develop powerful testing classes using scripting code to perform complex tasks, and then their less technical users will use the visual ODT interface to create and populate instances of those testing classes.

As for some of the other benefits afforded by ODT, AutomatedQA made it possible to design an entire test project using nothing but test objects within the ODT panel. If you examine the ODT object, you’ll find the method ODT.Data.Run. What this method does is to begin traversing through the hierarchy of test objects, executing their various methods. This is like a highly robust version of TestCompletet’s Test Suites panel. If we were using the ODT panel to conduct our customer/orders testing, we might have multiple customer objects, each of which own multiple orders, which in turn own multiple items (figure 7).

 

Figure 7 – multi object level ODT panel.

Note that in figure 7, I’ve highlighted and color-coded the image to clarify discussion. In the image, the blue-tinted items are properties of the Customer objects. Customer01, 02, etc. each have their own information such as FirstName, Addr and Orders. Because Orders is an array, it can own any number of Order objects. There are two orders in our screenshot – they are yellow and contain (among other properties) objects that represent line items in the order.

Each of these different objects will have methods which, presumably, will know how to enter the object’s property values into the tested application and validate their entry. When ODT.Data.Run is called, TestComplete will begin executing all the appropriate methods of the testing classes.

Another feature of the ODT panel worth mentioning is that of filtration and selection. Since the ODT mechanism is designed to allow users to run an entire test project visually, from the ODT panel, we’ve incorporated not only the ability to specify which branches are enabled and disabled, but also a means to filter out objects based on live data. I won’t go into detail on these features here; they’re covered in the help system (see Controlling Object-Driven Tests).

Explaining the ODT Demo Project

Included with the TestComplete installation are a number of demo test projects; among them is a sample of object-driven testing. It’s a good example of some of what can be accomplished with ODT, but for some users, it will require some explanation.

For the purposes of discussion, I’ve created a UML-style class diagram for the ODT classes contained in the ODT demo project (C:\Program Files\Automated QA\TestComplete 3\Samples\Scripts\Object-Driven Testing\Object-driven Testing.pjs by default); it is in figure 8.

 

Figure 8 – the classes in the ODT demo.

It is important to note that the AbstractFindReplaceParent class that appears in the diagram does not actually exist in the demo. Instead, it’s possible for an array property (in this case, clsOperation.Values) to own instances of various class types. In this demo, the clsOperation object owns clsFindData and/or clsReplaceData objects; in a real object-oriented scenario, these classes could have descended from an abstract common ancestor.

Additional explanation is required for this demo. It shows one of many possible approaches for object organization within an ODT data group. The hierarchical approach (NotepadTest owning several File objects, which own several Operation objects…) is certainly a valid way to design and organize your test objects and test projects. It is not, however, the only way. Remember that you could use the ODT panel strictly as a visual entry form for maintaining data-driven testing data. Additionally, it’s common to use the Classes section of the panel to visually define test classes, and then to ignore the Data section; creating your testing objects entirely in code. This is quite common if you have a library of common UI testing classes. For instance, I have some ODT classes that simply click buttons, or select menu items (like the clsOperation classes in the ODT demo). When I want to click a button or a menu item, I can create an object in code (rather than visually in the ODT panel) and call that object’s “Click” method. This is very handy, as it has a very high ease-of-maintenance factor.

Conclusion

Object-driven testing is a very powerful feature of TestComplete with almost limitless possibilities. I hope to write numerous other papers on this subject, but for now, this introduction should serve to get you acquainted with the ODT concept. Make sure you keep the UML diagram in figure 8 handy for when you start examining the ODT demo project. Also, make sure you visit the help file frequently; for it has considerable information there about ODT.