3 Design Patterns for Keeping Your Test Automation Code DRY

You would be hard pressed to find a software engineer who doesn’t understand the importance of keeping code DRY (Don’t Repeat Yourself). Initially coined in The Pragmatic Programmer, the DRY principle states that “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” But while we generally remember to apply DRY principles to our production code, duplication remains an all too common problem with test automation code. Here are three design patterns that can help you keep your test automation code DRY.

1. Page Object Model

So you want to test the UI of your web app, how would you go about it? In the classical UI automation approach, you might write a simple script to simulate a human event (like filling out a form). But let’s say you had 20 different tests depending on the same page element; without some sort of abstraction, changing that element would require one to make the same update to 20 test routines accordingly.

Enter the Page Object Model (POM), a design pattern which involves modeling the different elements of your web app’s UI within your test code. It provides a layer of abstraction, where web pages are classes, page elements are class variables, and user interactions are methods on those classes — basically all the encapsulation and inheritance benefits of object oriented programming (OOP).

POM keeps your code DRY in the following ways:

Provides an object repository, a centralized location where you can update page elements for your tests.  
You can write page methods once in a POM class and reuse them across multiple elements.
Separating UI operations and flows from verification keeps code clean and manageable.

2. Page Factory

Since POM is an OOP pattern, it should come as no surprise that developers in the test automation scene came up with a corresponding factory pattern. If a factory is an object for creating other objects, than Page Factory is simply an extension of Page Object for creating other Page Objects and elements. In practice the Page Factory pattern is generally used to initialize elements of a Page Object or the Page Object itself.

3. Locator Management

Good locator management is essential to keeping your test code DRY. UI automation depends on your test tool’s ability to locate the various elements that make up a page or view. It’s not hard to imagine why locators are often the source of test fragility. Whether you change a data field in a form, move a button, or restyle a header, a small change in the UI is all it takes to cause a test to fail. While the need to keep your locators up to date is an inevitability of automation testing, there are a few best practices you can follow to effectively manage your locators:

Resist the temptation to store your locators in the properties file. Save locators with their associated page classes alongside your methods. This encapsulates your definitions by feature and makes it easier to eliminate locators that are no longer being used.
Use IDs whenever possible. IDs are unique (provided your HTML is built to W3C standards) and resolve faster in the browser than other locator types. Elements can still be located no matter where they are moved within the DOM tree. Don’t use IDs in cases where they will be generated dynamically (changed due to environment), this will cause your tests to become brittle and fail.

Understand when to use CSS and XPath. These locators can be used to select multiple elements across the DOM tree using combinations of CSS classes, element attributes and tag names. CSS locators can only be used to walk down the DOM tree. XPath locators can move both up, down, and across the DOM tree. In both cases, the key to writing robust code is to keep the paths short and simple, because a change to the DOM will immediately break the path and result in a failed test.

Test cases are repetitive by nature and encapsulated by design — it’s all too easy to cut development times to meet deadlines by copying and pasting blocks of code for each new feature that must be tested. Maintenance is manageable enough for the first 10-50 tests, but as that number grows to the hundreds and thousands, your test suite becomes untenable. But by following best practices and proven design patterns, it’s possible to maintain your test suite as you scale.

Looking to avoid the dangers of copypasta and spaghetti code altogether? Consider outsourcing the task of running and maintaining test scripts to our test automation experts on passbrains. Are you a professional tester looking to get paid for your skills? Sign up today to join our global talent pool.

Write new comment

Comments (0)

No comments found!