I think it is time to stop informing you that this is the newest edition to the most popular series- Design Patterns in Automated Testing. The so called by me Behaviours Design Pattern is a design pattern that you won't find in the list of all official design patterns. But as you know the design pattern is a general repeatable solution to a commonly occurring problem in software design. Behaviours Design Pattern increases the flexibility of your automated tests' API. You can create tests in the same manner as if you build LEGO bricks.

Definition The behaviours are small reusable workflows. They are combined in different tests. Usually, are executed by a special engine. Flexible automated tests' API

Improved tests' maintainability

Increased tests' readability

UML Class Diagram

Participants The classes and objects participating in Behaviours Design Pattern are: ​IBehaviour - Defines the interfaces for all behaviours. Contains all methods that one behaviour can override.

- Defines the interfaces for all behaviours. Contains all methods that one behaviour can override. Behaviour - The base class for all behaviours implements IBehaviour interface and holds empty virtual implementations of all methods.

- The base class for all behaviours implements IBehaviour interface and holds empty virtual implementations of all methods. PurchaseTestContext - Static class that contains all relevant information for single purchase related test like URL, prices and discounts.

- Static class that contains all relevant information for single purchase related test like URL, prices and discounts. ItemPageNavigationBehaviour - A concrete behaviour for the ItemPage class. It holds a logic for navigation.

- A concrete behaviour for the ItemPage class. It holds a logic for navigation. ItemPage - A concrete page object that provides different service operations that can be performed on the page. It is used in the concrete behaviours.

- A concrete page object that provides different service operations that can be performed on the page. It is used in the concrete behaviours. BehaviourEngine - It is the class that executes a list of behaviours' workflows. Behaviours Design Pattern C# Code Behaviours Design Pattern is a pattern that we discovered with my teammates during a period when we were searching for a better system tests' design. You won't find it in the books. A funny fact, when my manager first came up with this idea he named the pattern- Lego Design Pattern because you build the system tests in the same manner when you construct LEGO. Previously, we had really huge tests that contain massive workflows. However, often we had to customise them. In the past system tests' design, we used the Facade Design Pattern. So for every custom workflow, we needed to have different facade method. This led to enormous files and less maintainable and not so flexible tests.The main idea behind the Behaviours Design Pattern is that the huge workflow is split in multiple meaningful smaller workflows called behaviours. For example, the login can be a separate routine. IBehaviour Interface

The IBehaviour interface defines the small workflow. You can perform an action than wait for something to happen in the PostAct phase. After that, you can assert the state of the page. Also, you can verify the state before the initial action. Base Behaviour

Behaviour implements the IBehaviour interface. It only contains empty virtual methods. If the small concrete workflow doesn't have some of the operations, it doesn't override them. Concrete Behaviours

The test case that I going to automate is once again an online purchase process. You can find the full test case description in my article about the Null Object Design Pattern. The behaviour contains a reference to the related page object- ItemPage. An initialized instance of the page is passed to the constructor. This is a simple workflow because it holds only a single action. However, there are cases where you can have multiple actions inside your behaviours. For example, applying different discounts or asserting many taxes.

This is a more complicated example. The main action logs in the client then wait for the next page to load. The tests' related data is passed through the static class PurchaseTestContext.

Simple Behaviour Engine

Above you can find the simplest implementation of BehaviourEngine. We pass the ordered list of behaviours for the current tests' test case. Then the behaviours are created via the Activator class. After that, their actions are performed in expected workflow's order. Simple Behaviour Engine in Tests

First, you need to initialize the static PurchaseTestContext class. After that, you call the Execute method of SimpleBehaviourEngine. The desired test's workflow is passed as an ordered list of behaviour classes' types. Generic Behaviour Engine

It is basically the same class plus additional 20 overloaded generic methods. Instead of passing all types using the typeof operator, you can use these generic methods. Generic Behaviour Engine in Tests

It requires less code to configure the test's workflow. Override Part of the Small Workflows Sometimes, it comes in handy if you can override just a small part of the workflow. There are cases where you need to create a test for some less common scenario, so you don't want to create a separate reusable behaviour.

Above is the code of the extended behaviour engine that can contain overridden parts. Overridden Actions Behaviour Engine in Tests

The test is almost identical to the previous ones except the ConfigureCustomBehaviour method. There you set the type of the behaviour you want to override. You don't replace the whole workflow only part of it so you need to configure which is the part. Lastly, you pass an anonymous action that is going to be executed instead of the default action. Improve Behaviour Engine with Unity IoC Container

Instead of the Activator class, the Unity IoC container resolves the behaviours. Unity Behaviour Engine in Tests