Zeenyx Software

In the a previous post, we discussed how design patterns can be used in test automation to reduce the level of effort to develop and maintain automated tests. Here is another useful design pattern:

Pattern Name: Universal Tests

Problem:  There are many types of tests that are built to verify different aspects of the AUT’s GUI, including but not limited to field data types, field length, required/optional fields, tab order and adherence to standards. While the expected results for each of these tests will vary by field or by dialog, the requirements are common and reusable solutions can be easily developed.

Solution: The solution must provide a way to handle any number of pages or dialogs that may or may not appear. It must also provide a mechanism for customizing the responses to for each browser.

A universal test must be reusable for any page, window or dialog. It must not include any application specific references. Instead, it only encodes ‘rules’ that are applied to whatever is passed into the test.

The following is an example of a universal test:

Notice that the body of the class’s Main method, does not include any reference to the AUT. In this example test, it takes the FieldName which is the full name of the object to be verified along with the FieldLength which is the expected result. The automated test then gets the actual field length at runtime and makes the comparison.

Consequences:  Implementing a universal test requires an understanding of abstraction, but once the technique is mastered, there are many benefits. First, the approach increases productivity because once a solution is developed, it can be reused and since universal tests do not include any application specific references, they require no maintenance. Universal tests also promote standardization because they ensure that the same validations are applied uniformly. Furthermore, having a set of universal tests will serve as a checklist of the types of tests that should be executed for each page, window or dialog in the AUT.

When tight schedules have us racing to complete our testing tasks, it is easy to overlook the fact that many test requirements are common across applications and domains. Our first inclination might be to attack each new problem as if it were unique, but when we recognize an opportunity to apply a design pattern, we can save time, reduce maintenance and be assured that the solution has already been tried and tested.