‘Design patterns’ are a method of software testing that can greatly reduce manual and duplicated efforts.
As Romas Sirutavicius explains on his blog the primary reason why test automation frameworks fail is due to a poorly designed architecture, and design patterns can address this and common testing issues, such as those implementing the work lacking programming skills and familiarity with test automation.
Design patterns are grouped into three main categories of structural, creational and behavioural patterns, encoding previously developed best practices so they can be easily reused.
They explain and regulate object structures and behaviours, to implement ‘SOLID’ principles that help make software design more understandable, flexible and maintainable.
Page Object Model
The most popular design pattern is the Page Object Model, commonly used to build test automation frameworks for UI test cases. Selenium, a key tool that 2i uses, explains how to implement them here.
They eliminate the need to write duplicate code, creating page components like input fields and buttons, that are reused when building other page objects, and enable encapsulation and abstraction of web elements.
We do this by modelling the framework to the model of the pages of the application. In the application you might have a Login Page and Orders Page.
Under this model, for each web page in the application, there should be a corresponding Page Class. This Page class will identify the WebElements of that web page which contains Page methods which perform operations on those WebElements. By naming the methods as easily readable and assigned by the task they are performing the code that is written is easy for others to understand. The underlying low-level test code is encapsulated and hidden.
The advantages of using this powerful design pattern is to create a layer of abstraction so the test code is not so tightly coupled to the HTML elements on a page and by decoupling the code we can build more robust tests. With the elements separated from the tests, if the elements change, they can be updated in one place (page class), rather than having to update lots of tests, thus reducing maintenance costs.
Below is a representation of the Page Object Model design pattern.
There are some slight considerations required to use this model. It requires adequately skilled technical QA resource to carry out this effectively in order to support the ongoing maintenance and testing of new features introduced to the application.
However, after the initial training and set up costs the advantages of using the Page Object Model greatly outweigh the disadvantages and it plays a key part to have an efficient, scalable and robust framework in place.
Clients like the Scottish Government use this approach to minimise their technical debt and improve the efficiency of their software development and testing workflow. Using a Behaviour Driven Development approach for the new Social Security application they are building they apply the technique for the web UI’s, screen options for steps like login, address lookup and benefits selection that feature multiple widgets like buttons and drop down menus.
By defining common page class types it decouples the logic from the HTML and the developers can change these elements without needing to change the underlying test code, engendering a much more agile code base and importantly, given the Scottish Government operates multiple suppliers across their estate, a consistent and easily understood framework for testing by different teams, greatly reducing errors and work effort required to successfully deploy new applications.
