A big part of being successful with your automation projects is reusing known test patterns that have been shown to help automation script reliability.
An automation testing design pattern is simply a solution that has shown to be successful again and again. These testing patterns also are considered best practices for any object-oriented programming development project.
In this blog post, you’ll learn:
- The importance of automation testing design patterns
- The top 4 automation design patterns
- The other 86 automation testing patterns
Why Are Automation Testing Design Patterns Important?
It’s a given that your applications are going to change over time.
And since you know change is going to happen, you should start off right from the beginning using best practices or design patterns.
Doing so will make your automated tests more repeatable and maintainable.
Here are some common automation testing design patterns many teams use to help them create more reliable test automation and improve their test logic.
Top 4 Test Automation Design Patterns
1. Page Objects
One popular strategy to use when creating your test automation is to model the behavior of your application.
This can be achieved by creating simple page objects that model the pieces of the software you’re testing against.
For example, you would write a page object for a login or a homepage. Following this approach correctly makes use of the single responsibility principle.
If anything changes—say, an element ID—you need only go to one place to make the change, and all of the tests that use that page object will automatically pick up the changes without you doing anything further. The test code needs to be updated in only one place. This also helps reduce code duplication.
Page objects also hide the technical details of HTML fields and CSS classes behind methods that have easy-to-understand names.
Being mindful when naming your methods has the extra benefit of helping to create a nice, readable test application programming interface (API) that a less technical automation engineer can quickly start using.
This pattern also adheres to the popular software development practice, the DRY principle (Don’t Repeat Yourself).
The DRY principle basically means that each piece of logic should be coded once and only once. The duplicate code makes the code harder to maintain; the less code you write, the better, since more code to maintain means the greater chance you have for bugs to creep into your test framework.
This single software design pattern can easily solve the bulk of your testing problems, but it’s not a silver bullet. It will, however, help you take a huge leap forward in making your automated functional tests more stable.
Some test engineers have claimed that the Page Object pattern regularly violates the principle that a class should have only one reason to change.
To avoid this, many have turned to the ScreenPlay pattern, which was first described by Antony Marcano (@AntonyMarcano) with contributions from Andy Palmer (@AndyPalmer), Jan Molak(@JanMolak), and others.
Join the 2018 Guild! Register Today
2. Screenplay Pattern
Page objects are a good place to start making your test maintainable, but if you’re not careful, they can grow out of control over time.
The Screenplay Pattern (formerly known as the Journey Pattern) is the application of SOLID design principles to automated acceptance testing and helps teams address these issues. It is essentially what would result from the merciless refactoring of Page Objects using SOLID design principles.
The Screenplay Pattern (formerly known as the Journey Pattern) is the application of SOLID design principles to automated acceptance testing and helps teams address these issues. It is essentially what would result from the merciless refactoring of Page Objects using SOLID design principles.
The Screenplay pattern takes page objects and chops them down into really tiny pieces. Some testers tell me that this has made their multiple tests much more maintainable and reliable.
Another significant benefit is that it makes test scripts more readable.
I first heard about the Screenplay Pattern at the 2017 Automation Guild session by John Smart (@Wakeleo), creator of one of my favorite test automation frameworks, Serenity.
The screenplay uses the idea of actors, tasks, and goals to express tests in business terms, rather than in terms of interactions with the system. In Screenplay, you describe tests in terms of an actor who has goals.
Here is an example:
At first, it may seem like a lot more work to use this pattern than, say, Page Objects, but John has mentioned that using this approach has been a huge time saver for teams he’s worked with due to the decrease in the maintenance needed.
3. Ports and Adapters
The Ports and Adapters design strives to make sure you are using the Single Responsibility Principle so that an object should do only one thing and have only one reason to change.
When you apply this to your automation testing process, make sure to decouple your test case code to allow you to swap slow components with fast simulators so that you can run your test and the app you’re testing in the same process.
Remove all networking and input/output, so nothing is slowing down the test suite. Of course, this is not easy to do, but the more you strive to do this when creating UI automation, the better off you will be.
This pattern was described to me in my interview with the creator of Cucumber, Aslak Hellesoy (@aslak_hellesoy), as a strategy for getting really fast feedback from end-to-end Cucumber tests.
Aslak also recommended a resource called Todo-subsecond that I added to my Top Resource for Test Automation Engineers post. It's a tiny application with full-stack acceptance tests that can run in milliseconds. Its purpose is to illustrate the essential techniques to achieve this in any system. Through a series of exercises, you’ll get familiar with a particular way of doing test-driven and behavior-driven development.
4. Presenter First
Presenter First is a modification of the model-view-controller (MVC) way of organizing code and development behaviors to create completely tested software using a test-driven development (TDD) approach.
I first learned of this automation testing pattern when interviewing Seb Rose (@SebRose), one of the contributors to the Cucumber project and author of the book Cucumber for Java.
He mentioned that if you draw out the MVC pattern as blocks and arrows, you can see that the view, which is your UI, has well-defined channels of communication with the model and the controller. If you can replace those during runtime with models and controllers that your test creates and controls, then there is no reason why you can’t just test that the UI behaves in the way that you want.
You can also set your model and controller to mimic all sorts of odd behaviors, like a network going down.
86 Other Automation Testing Patterns
I wrote this article months ago but never published it.
I was feeling pretty good about my list until I interviewed Seretta Gamba, author of the newly released book A Journey through Test Automation Patterns, where she and her co-author Dorothy Graham cover 86 patterns!
They break their testing patterns into four separate categories:
- Process patterns
- Management Patterns
- Design Patterns,
- Execution patterns
The ones I’ve covered all fall under design patterns, but there are a host of others that address issues not just related to code.
For example, there are patterns that address poor culture and management patterns that, in my experience, tend to kill most automation testing efforts.
For the full list, check out the wiki on strategy design patterns, or get their awesome new book now available on Amazon.
