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|