4 best design patterns for automated testing (and 86 more)
Most of the success of your automation projects lies in reusing well-known testing patterns, which, as already proven, help to increase the reliability of automation scenarios.
An automated testing design pattern is a simple solution that proves its effectiveness to the world day by day. These templates are also considered best practices for any project built with object-oriented programming.
Why are design patterns so important for automated testing?
Take it for granted that your applications will change over time.
And since you know that change will happen one way or another, you should use the best practices and design patterns from the very beginning. They will make your tests reusable and easier to maintain.
Here are a few common automated test design patterns that many teams use to create robust test automation and improve the whole testing logic.
Page Objects
Example of Page Object by Nikolay Advolodkin from Automation Guild 2017
One of the popular strategies used in testing automation is to model the behavior of your application.
To do this, you can use simple page objects that simulate those pieces of software that you are testing.
For example, you can write a page object for a login page or home page. This approach correctly reflects the principle of shared responsibility.
If something changes, say, the ID of the element, then you will need to change only one place in the code, and all tests using this page object will automatically receive this change without unnecessary action. The test code should only be updated in one place. This approach also helps reduce code duplication.
Page objects also hide the technical details of HTML and CSS behind methods with simple and clear names.
Attentiveness to the naming of your methods has the additional advantage of helping to create a nice, readable application programming interface (API) that a less technically savvy programmer can quickly start using.
This pattern also adheres to popular software development practices. DRY (Don’t Repeat Yourself, do not repeat).
Basically, the DRY principle means that for each part of the logic, one piece of code and no more should be responsible. Duplication in code makes it difficult to maintain; the less code you write, the better, since more supported code means more chance that an error will creep into your testing framework.
This software design template alone can easily solve the bulk of your testing problems, but it is not a panacea either. However, it will allow you to take a big step forward, making your automated functional tests more stable.
Some testers argue that the Page Object pattern often violates the principle that a class should have only one reason to change.
To avoid this, many turn to the script, which was first described by Anthony Marcano (<a href=”https://twitter.com/AntonyMarcano”>@AntonyMarcano) with the participation of Andy Palmer (@AndyPalmer), Jan Molak (@JanMolak) and others.
Screenplay Pattern
Page objects are a good way to start making your tests maintainable, but if you don’t be careful, they can still get out of hand over time.
The Screenplay pattern (once known as the Journey pattern) is an application of design principles SOLID for automated acceptance testing and helps teams solve these problems. That is, in fact, this is what was the result of ruthless refactoring of Page Objects using the SOLID design principles.
The Screenplay pattern takes page objects and breaks them into really tiny pieces. Some testers say this has made their tests more maintainable and reliable.
Another significant advantage is that it makes test scripts more readable.
I first heard about Screenplay pattern at Automation Guild Session in 2017 from John Smart (@Wakeleo), creator of one of my favorite test automation frameworks, Serenity.
Screenplay uses the idea of actors, tasks and goals to formally describe the tests, refusing the terms of interaction with the system. In Screenplay, you describe the tests in terms of an actor who has goals.
Here is an example:
An example of the implementation of the Screenplay pattern from the Automation Guild Session 2017 by John Smart
At first glance, it may seem that using this pattern is much more difficult than the same Page Objects, but John mentioned that using this approach saves the teams he worked with a lot of time by reducing the cost of maintenance and support.
Ports and Adapters
The architecture of ports and adapters aims to ensure that you are using principle of shared responsibility, that is, a particular object must do one thing and have only one reason for the change.
When you use it in automation, make sure that you separate the test case code from everything else in order to be able to swap slow components and fast simulators, thereby allowing you to run the test and the application under test in one process.
Get rid of networks and I / O so that nothing slows down the test suite. Of course, this is not easy to do, but the more you strive for this when creating user interface automation, the better it will be for you.
I learned about this pattern during an interview with the creator CucumberAslak Hellesoy (@aslak_hellesoy). He described it as a strategy for getting quick feedback from Cucumber end-to-end testing.
Aslak also recommended a resource called Todo-subsecondwhich I added to my post Top Resource for Test Automation Engineers. This is a tiny application with full-stack acceptance tests that can run in milliseconds. Its purpose is to illustrate the basic methods for achieving this in any system. After completing a series of exercises, you will learn a special way to implement test-driven and behavior-driven development.
Presenter first
Presenter First is a modification of the model-view-controller (MVC) for organizing code and development to create fully tested software using a test-driven development approach (TDD).
I first learned about this pattern from an interview with Sab Rose (@SebRose), one of the contributors to the Cucumber project and the author of Cucumber for Java.
He said that if you draw the MVC pattern in the form of blocks and arrows, you will see that the view, which is your user interface, has clearly defined connections with the model and the controller. If in runtime you can replace them with the models and controllers that your test creates and controls, then there will be no reason why you cannot verify that the user interface does not behave the way you want.
You can also customize your model and controller so that they simulate all kinds of strange behavior, for example, a network failure.
86 other automated testing patterns
I wrote this article many months ago, but never published it.
I was sure of my list until the moment I spoke with Seretta Gambaauthor of a new book A Journey through Test Automation Patternswhere she and her co-author Dorothy Graham talk about 86 patterns!
They break down patterns into four distinct categories: process patterns, control patterns, design patterns, and execution patterns.
The ones I described refer to design patterns, but there are many other patterns that solve problems not only with code.
For example, there are patterns that relate to poor corporate culture and management models, which, in my experience, tend to nullify all efforts to automate testing.
For a complete list, check out wiki for design patterns or book yourself a book with Amazon.
