It is understandable that someone new to test automation would wonder whether the benefits of defining application objects are worth the effort. After all, isn’t it more expedient to use a recorder that references objects directly? It is a question that occasionally surfaces during a comparison of automated testing tools. Yet the real merits of an object-based solution are difficult to foresee during the relatively short evaluation period. Those benefits may not be understood until the first maintenance cycle occurs and the user is tasked with updating tests to get them to run successfully against the ‘next’ version of the target application. This is where the rubber meets the road. The purpose of this paper is to present the ‘long view’ and demonstrate how object definitions reduce the level of effort over time.

What is an Object Definition?

An object definition is an abstraction that provides a way to refer to an application object by name so that future changes in the class or means of identifying the object do not impact the automated tests that refer to that object.

In AscentialTest, an object definition is called an ‘App Object’. It has three components:

• Object Class – the type of object
• Object Path – the identifier or locator of the object, usually via an object attribute
• Object Name – the arbitrary name for the object, which the user can change

The abstraction allows the object to be referred to indirectly without regard to the implementation details of the object. In AscentialTest, tests refer only to the Object Name. If the class or path needs to be modified to reflect changes in the target application in the future, tests are unaffected because they only reference the Object Name.

Misconceptions

The predominant misconception about object definitions is that they add an unnecessary and time-consuming step to the process of building automated tests. While it’s true that defining objects is an additional step, the process is neither difficult nor time-consuming. In fact, it is accomplished in AscentialTest largely through a drag and drop process from a smart image called a ‘snapshot’ to the repository that contains the object definitions. After an initial learning period, users can typically define a page or screen with all of its objects in just a few minutes. It is also important to understand that defining App Objects is a one-time task. Once the App Objects have been captured in the beginning of the testing project, they will be used over the lifetime of the testing project, where the benefits will be continually realized.

What are the Primary Benefits of Object Definitions?

The most immediate benefit, and one that users do understand during the evaluation process, is that App Objects enable the ‘Action Builder’ which provides a script-less way to create robust, maintainable tests through drag and drop. Since the class of each object is part of its definition, AscentialTest ‘knows how’ the object behaves and is able to provide ‘set’, ‘get’ and ‘verify’ actions.

The user is able to add actions to tests in a fashion that is easier to use than a traditional recorder. They select objects in the snapshot image and then choose from a list of action types. This approach eliminates the need for the user to learn a scripting language and escapes all the downsides of recorders.

For list-based objects like List Boxes, Popup Lists and Radio Lists, an object definition is associated with the list of items contained in the object. AscentialTest extracts the list of items and stores them in a special type like the ‘StateString’ displayed below for the state abbreviations contained in the ‘State’ Popup List.

That list of values is used to provide a pick-list where ever test data requires the selection of a state abbreviation to be input to the ‘State’ Popup List.

The least obvious, but by far the most important benefit of object definitions, is the long term impact that they have on the on-going maintenance of automated tests. As mentioned above, object definitions create an abstraction, but how does that abstraction impact test maintenance? What it means is that if the implementation of an application object changes, the user only needs to change the definition of the object. All of the references to that object in the automated tests will remain unchanged. The object may have been referenced tens, hundreds or even thousands of times, but only one change will be required to update the object’s class or path.

Let’s take a look at a real-life example from an AscentialTest user:

The image above depicts two versions of a target application. In the first version, the ‘Storage Location’ field was implemented as a WebTextField. In the second version, it was implemented to a WebPopupList. Although it is not obvious by looking at the two versions of the application, the image below shows how the entire structure of the page was re-implemented in Version 2. Notice how the original version implemented the ‘table’ as a collection of WebBlock elements, whereas newer version used a WebTable element:

The implications of these changes on a set of automated tests that are not object-based are significant. In fact, it would likely take as long to locate the impacted tests and make the necessary changes as it took to create the tests in the first place.

Let’s review the changes that would be necessary to update just a single action. The action depicted below sets the text to the ‘StorageLocation’ field in version 1 of the target application:

That same action would need to be changed to the following in version 2 (note an elipse replaces some of the levels in order to get the action to fit on one line below):

Consider how impacts of a change like this one might affect tens or hundreds of automated tests and this is only one change to the application.

On the other hand, object definitions reduce the level of effort to a single change. In this case, only the class of the ‘StorageLocation’ field needed to be changed from a WebTextField to a WebPopupList:

The action that sets the text to the ‘StoreageLocation’ field would not be impacted by the change in any way. Here is the action for both versions 1 and 2:

What this means to the tester is that no steps or tests would need to be modified. That’s one of the reasons why your tests will be ready when you need them when you use AscentialTest.

Additional Benefits

There are some additional benefits from the use of object definitions which may or may not apply to a given testing project. If a target application is deployed on more than one platform, App Objects make it possible to reuse a common set of automated tests across multiple platforms. For example, several AscentialTest customers have successfully implemented their tests to run on both thick and thin versions of their target applications. Since their tests refer only to the names of application objects, they maintain two sets of object definitions to which the common set of tests refer. Likewise, AscentialTest provides a mechanism for translating the paths of App Objects so that a single set of tests can be run against multiple localized language versions of the target application. The time and cost saving is significant and the organization is assured that the same exact tests are being run on the different application versions.

Conclusion

Object definitions provide benefits that far outweigh the costs of creating them. In AscentialTest, they are created quickly and easily in a drag and drop environment. Although they do add a step to the process of building automated tests, they provide the following benefits:

• Enable object/action drag and drop to add actions to tests without scripting.
• Provide pick-lists when inputting test data values for list-based controls.
• Significantly reduce the cost and level of effort to keep tests up to date as the target application changes over time.
• Provide the ability to use a set of common tests across multiple implementation platforms.
• Provide the ability to use a set of common tests across multiple language locales.

If you have any questions about object definitions and how they impact the long term ownership of automated tests, please contact Zeenyx Support at [email protected] for more information.