Object orientation, the least talked about component of test automation, might be the most important factor. In this column, Dion Johnson explains how effective test automation is heavily reliant on objects.
There are times when my right brain activity really increases, which leads me to an extremely poetic state of mind. For this reason, I'd like to begin this column with a poem that I wrote about test automation called "The Object of My Desire":
Roses are red,
Violets are blue,
The whole world thrives on objects,
And automation does too.
While I know that you readers are probably at your computers giving this artistic mastery of the written language a spontaneous standing ovation, I must request that you compose yourselves, so that I may draw your attention to the subtle-or maybe not so subtle-message within. That message is that effective software test automation implementation is reliant on-even married to-concepts surrounding software objects. This is a little-explored but important fact, because a firm understanding and utilization of object-oriented concepts is a key ingredient for software test organizations that desire to implement an effective test automation effort. In this column I identify common object-oriented concepts and then explore various ways in which these concepts lead to desired levels of test automation.
Object-oriented programming is a type of programming in which programmers can define modular components called classes (objects) that allow for the efficient creation of software. These objects may then be arranged into a hierarchy known as an object model. When talking about object-oriented concepts we must understand the basics of classes and object models, so let's begin there.
A class is a template for multiple objects with different features, and each class may have properties, operations (methods that can be applied to the object), events, and collections. Properties are simply object variables that may be maintained throughout the life of the object, while methods are repeatable actions that may be called by a script that references the object. Events are also repeatable actions, but these actions, unlike methods, are not explicitly called by a script; they are automatically executed based on an action performed by a user (e.g., mouse click, scroll, etc.) A collection is a set of data or objects that are of the same type.
To help further explain these concepts, let's examine the class illustrated in figure 1.
|Figure 1: Class/object illustration|
The class in the figure is a Button class, and it has two properties that define the features of all buttons created from this class: shape and text. There are two objects (instances of the class) illustrated in the figure, and both have shape and text properties, but the values for shape and text are different for each button object. The first button is rectangular in shape, and has the "R Button" text on it, while the second button is oval in shape, and has the "O Button" text on it. Each button also has a method that can be performed on it-the click method, which means that you can click the button. The two button objects collectively make up what is called the Buttons collection. This collection provides the capability of referring to each button based on its position in the group.
Therefore, object 1 can be referred to in two ways:
- By its collection location (i.e., Buttons Collection object 1)
- By its properties (i.e., the button that has a rectangular shape and reads "R Button")
Many, if not most of today's software applications are built using object-oriented concepts, and the objects that compose the application (e.g., windows, buttons, images, links, textboxes, etc.) are arranged into a hierarchy known as an object model.
The Marriage to Automation
With this information in place, the question becomes "How do these object-oriented concepts support my