Advanced Behaviours Design Pattern in Automated Testing Part 2

Advanced Behaviours Design Pattern in Automated Testing Part 2

My last two articles were dedicated to the Behaviours Design Pattern. It is a pattern that eases the creation of tests through a build process similar to LEGO. This article, part of the Design Patterns in Automated Testing Series, is going to suggest a new concept how to improve the behaviours driven tests even further. It is going to ease the actions’ configuration through the introduction of behaviours’ definitions.

UML Class Diagram

classDiagram
    BehaviourEngine ..> IBehaviour
    BehaviourEngine ..> UnityContainerFactory
    IBehaviour <|.. ActionBehaviour
    ActionBehaviour <|-- ItemPageNavigationBehaviour
    BehaviorDefinition <|-- NavigatePageBehaviorDefinition
    ItemPageNavigationBehaviour ..> NavigatePageBehaviorDefinition
    ItemPageNavigationBehaviour ..> UnityContainerFactory
    ItemPageNavigationBehaviour ..> ItemPage
    class IBehaviour {
        <<interface>>
        +Execute()
    }
    class BehaviourEngine {
        +Execute()
    }
    class ActionBehaviour {
        +Execute()
        +PerformAct()
    }
    class BehaviorDefinition {
        +Type BehaviorType
    }
    class NavigatePageBehaviorDefinition {
        +string ExpectedUrl
    }
    class ItemPageNavigationBehaviour {
        +itemUrl
        +PerformAct()
    }
    class UnityContainerFactory {
        +GetContainer()
    }
    class ItemPage {
        +Navigate()
    }

The classes and objects participating in the enhanced Behaviours Design Pattern are:

  • IBehaviour

    Defines the interfaces for all behaviours. Contains only a single Execute method.

  • ActionBehaviour

    The base class for all actions-only behaviours. Contains only two methods PerformAct and Execute.

  • UnityContainerFactory

    A class that creates and holds a single global instance to a Unity IoC container.

  • ItemPageNavigationBehaviour

    A concrete behaviour for the ItemPage class. It holds a logic for navigation. Its is an action behaviour.

  • ItemPage

    A concrete page object that provides different service operations that can be performed on the page. It is used in the specific behaviours.

  • BehaviourEngine

    It is the class that executes the list of behaviours’ workflows.

  • BehaviourDefinition

    The base class for all behaviours’ definitions. It holds the type of the definition’s behaviour.

  • The concrete definition for ItemPageNavigationBehaviour. It extends the BehaviourDefinition base class and contains the property for the navigation URL.

What Are the Problems That We Try to Solve?

The initial version of the behaviours had one major shortcoming- the inability to pass parameters to the behaviours. To do their job they needed a static test context class. Another considerable drawback was that the behaviours’ executor was not flexible, it was hard to change its hard-coded workflow.

Enhanced Behaviours Design Pattern through Definitions

The new concept steps on the previously improved design. You can read more about it in my previous article- Advanced Behaviours Design Pattern in Automated Testing Part 1. The main difference compared to the earlier design is that the behaviours are split into two separate classes- behaviour and definition. The definition holds all parameters needed for the work of the workflow. The another change is that the engine now requires the definitions instead of behaviours.

BehaviorDefinition Base Class

public abstract class BehaviorDefinition
{
    public BehaviorDefinition(Type behaviorType)
    {
        this.BehaviorType = behaviorType;
    }
    internal Type BehaviorType { get; private set; }
}

Nothing special about this class. It only holds a reference to its behaviour.

public class NavigatePageBehaviorDefinition : BehaviorDefinition
{
    public NavigatePageBehaviorDefinition(string expectedUrl) :
    base(typeof(NavigatePageBehavior))
    {
        this.ExpectedUrl = expectedUrl;
    }
    internal string ExpectedUrl { get; private set; }
}

That is the class that holds all parameters required for the Navigation Page behaviour. It contains the navigation URL. Also, we pass the type of the NavigatePageBehaviour to the base constructor. It is necessary for the proper work of the engine.

public class NavigatePageBehavior : ActionBehaviour
{
    private readonly string expectedUrl;
    public NavigatePageBehavior(NavigatePageBehaviorDefinition definition)
    {
        this.expectedUrl = definition.ExpectedUrl;
    }
    protected override void PerformAct()
    {
        Console.WriteLine(this.expectedUrl);
    }
}

The difference compared to the earlier version is that the navigation URL now is got from the definition instead from the behaviour. The single responsibility principle is followed more closely.

Enhanced Behaviour Engine 

public static class BehaviorEngine
{
    public static void Execute(params BehaviorDefinition[] behaviorDefinitions)
    {
        foreach (var definition in behaviorDefinitions)
        {
            var behavior =
            UnityContainerFactory.GetContainer().Resolve(
            definition.BehaviorType,
            new ResolverOverride[]
            {
new ParameterOverride("definition", definition)
            }) as Behavior;
            behavior.Execute();
        }
    }
}

We pass the definitions to the Execute method. However, their behaviours are executed. They are resolved through the Unity IoC container that gets their instances based on the definitions’ behaviour types. Unity injects the instance of the current definition as a parameter override of the ‘definition’ constructor’s parameter.

Definition Behaviours in Tests

The usage in tests is straightforward.


public void Purchase_SimpleBehaviourEngine()
{
    string itemUrl = "/Selenium-Testing-Cookbook-Gundecha-Unmesh/dp/1849515743";
    BehaviorEngine.Execute(
    new NavigatePageBehaviorDefinition(itemUrl));
}

For more detailed overview and usage of many more design patterns and best practices in automated testing, check my book “Design Patterns for High-Quality Automated Tests, C# Edition, High-Quality Tests Attributes, and Best Practices”.  You can read part of three of the chapters:

Defining High-Quality Test Attributes for Automated Tests

Benchmarking for Assessing Automated Test Components Performance

Generic Repository Design Pattern- Test Data Preparation

Related Articles

Design Patterns

Decorator Design Pattern in Automated Testing

In my articles "Strategy Design Pattern" and "Advanced Strategy Design Pattern", I explained the benefits of the application of Strategy Design Pattern in your

Decorator Design Pattern in Automated Testing

Design Patterns

Page Objects- Partial Classes String Properties- WebDriver C#

Editorial Note: I originally wrote this post for the Test Huddle Blog. You can check out the original here, at their site.

Page Objects- Partial Classes String Properties- WebDriver C#

Design Patterns

Page Objects That Make Code More Maintainable

If you have read some of my previous posts, most probably you have checked some of my articles about Design Patterns in Automated Testing. One of the most promi

Page Objects That Make Code More Maintainable

Design Architecture, Design Patterns

Highlight Elements on Action- Test Automation Framework Extensibility through Observer Design Pattern

As you know, in past articles from the Design and Architecture Series I wrote about the 5th generation test automation frameworks or as I like to call them Full

Highlight Elements on Action- Test Automation Framework Extensibility through Observer Design Pattern

Design Patterns

Advanced Specification Design Pattern in Automated Testing

In my last publication from the Design Patterns in Automated Testing Series, I explained to you how you can benefit from the usage of the Specification Design P

Advanced Specification Design Pattern in Automated Testing

Design Patterns

Singleton Design Pattern in Automated Testing

Ensure a class has only one instance and provide a global point of access to it.Instance control– prevents other objects from instantiating their own copies of

Singleton Design Pattern in Automated Testing
Anton Angelov

About the author

Anton Angelov is Managing Director, Co-Founder, and Chief Test Automation Architect at Automate The Planet — a boutique consulting firm specializing in AI-augmented test automation strategy, implementation, and enablement. He is the creator of BELLATRIX, a cross-platform framework for web, mobile, desktop, and API testing, and the author of 8 bestselling books on test automation. A speaker at 60+ international conferences and researcher in AI-driven testing and LLM-based automation, he has been recognized as QA of the Decade and Webit Changemaker 2025.