All about design patterns in automation testing.

Test automation has its own set of tasks, so there is a set of useful design patterns for this area.

Design patterns are a controversial topic. If you Google this question, you will find many other examples of design patterns in design automation that are used in various teams. In this article, I would like to collect all the patterns accumulated over several years of personal practice that I had to deal with. The article does not include patterns that I consider questionable, not useful, or that he has not encountered.

There is no such thing as a “good design pattern” or a “bad design pattern”. The term “design pattern” was coined as a formulation of the problem and the proposed solution. It is very important not just to bring a design pattern to your project. It is important to understand their purpose, problems, how and how it can help you, and what problems it can solve.

There are many problems in design and development automation, and when faced with these problems, people formulated patterns. Initially, the classic Patterns were formulated a long time ago by the four who published the book Design Patterns.
The book outlines all the patterns they encountered in the object-oriented world at that time. There is a problem — there is a solution, and for a long time, this concept of design patterns grew and developed, adding new patterns.

The main drivers of almost all patterns in test automation are the following factors: reliability, clarity, flexibility, maintainability, and stability.

I divided all the patterns into several groups.

Structural Patterns.

Structural patterns, the main task of which is to structure the code of our tests — to simplify support, avoid duplicates, and problems with obfuscation. This makes it easier for test engineers working with the same issues to understand and change them, and easier to maintain.

• Page Object
• Fluent/Chain of invocations
• Factory/Page Factory
• Page Element/Composite List of Items Link Menu Panel Checkbox
• No duplicated code
• Loadable Component
• Strategy

Data Patterns.

We would like to pull data and data management away from the test logic as far as possible, in order to remove the amount of so-called boilerplate code from our tests. This will make the logic even more transparent and easier to maintain for those who write these automation scripts.

• Value Object
• Builder
• Assert Object/Matchers
• Data Registry
• Object Pool/Flyweight
• Data Provider

Technical Patterns.

Technical patterns serve to make the technical aspects separate from the test logic, and often to provide additional low-level control over the technical part.

• Decorator
• Proxy

Business Involvement Patterns.

We try to bring product owners, business analysts, and other people responsible for requirements as close to test automation as possible so that they see the benefits of it, and they invest in it as much as we do, because we are a single team.

• Keyword Driven Testing
• Behavior Specification
• Behavior Driven Development
• Steps

You can’t just write a cool automation script. You can write a single automation script, but make sure that as the number of these cool tests increases, you don’t lose any speed or time that you spend supporting these tests.

If you don’t want to constantly waste time maintaining and fixing tests, you should understand that there are design patterns that will allow you to avoid these problems in the future. By knowing these design patterns, applying them locally, and understanding the issues, you can make your automation scripts better faster, more productive, and so on.