Click here to Skip to main content
15,867,771 members
Articles / Programming Languages / Assembler

Advanced Behaviours Design Pattern in Automated Testing - Part 1

Rate me:
Please Sign up or sign in to vote.
5.00/5 (3 votes)
15 May 2016Ms-PL4 min read 10.9K   2   1
Describes how to improve even further the behaviours design pattern tests through new base classes and usage of Unity IoC container.

In my previous article dedicated to Behaviours Design Pattern, I shared with you how you can use the pattern to build system tests like a LEGO. The new article from the Design Patterns in Automated Testing Series is going to explain how you can improve even further your behaviours driven tests.

UML Class Diagram

Image 1

Participants

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

  • IBehaviour- Defines the interfaces for all behaviours. Contains only a single Execute method.
  • AssertBehaviour- The base class for all assert-only behaviours. Contains two methods- Assert and Execute
  • ActionBehaviour- The base class for all actions-only behaviours. Contains only two methods PerformAct and Execute
  • WaitableActionBehaviour- Base class for all more complex behaviours that can contain simultaneously actions, asserts and wait logic. 
  • 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.
  • BehaviourExecutor- It is the class that executes the list of behaviours' workflows.

What Are the Problems That We Try to Solve?

In the previous examples, there was one major problem and that was the inability to pass properly the parameters to the behaviours. They all depended on a static test context class. As you probably know, the usage of static is not a best practice. The another issue that I saw was that the workflow's definition in the ExecutionEngine was somehow not flexible. If you need to add a new step you need to apply the change in the primary class that almost all tests depend on. I wanted to improve the flexibility of the tests.

Behaviours Design Pattern C# Code

One of the main differences compared to the previous examples is that the IBehaviour interface contains only a single method- Execute.

IBehaviour Interface Changes

C#
public interface IBehaviour
{
    void Execute();
}

Another major difference is that there are multiple base behaviours classes based on the use cases they need to solve in this variation of the behaviours design pattern. There is an actions-only and asserts-only classes. I believe that this leads to better OOP design instead of overriding only a part of the provided methods.

Actions-only Base Class

C#
public abstract class ActionBehaviour : IBehaviour
{
    public void Execute()
    {
        this.PerformAct();
    }

    protected abstract void PerformAct();
}

Assert-only Base Class

C#
public abstract class AssertBehaviour : IBehaviour
{
    public void Execute()
    {
        this.Assert();
    }

    protected abstract void Assert();
}

Waitable Action Base Class

C#
public abstract class WaitableActionBehaviour : IBehaviour
{
    public void Execute()
    {
        this.PerformAct();
        this.PerformPostActWait();
    }

    protected abstract void PerformAct();

    protected abstract void PerformPostActWait();
}

The class is useful when you need to perform an action and then wait for something, for example, wait for the page to load or for an element to become visible.

Waitable Assertable Action Base Class

C#
public class WaitableAssertableActionBehaviour : IBehaviour
{
    public void Execute()
    {
        this.PerformPreActWait();
        this.PerformPreActAssert();
        this.PerformAct();
        this.PerformPostActAssert();
        this.PerformPostActWait();
        this.PerformPostActWaitAssert();
    }

    protected virtual void PerformPreActWait()
    {
    }

    protected virtual void PerformPreActAssert()
    {
    }

    protected virtual void PerformAct()
    {
    }

    protected virtual void PerformPostActAssert()
    {
    }

    protected virtual void PerformPostActWait()
    {
    }

    protected virtual void PerformPostActWaitAssert()
    {
    }
}

The class is almost identical to the ones from the previous examples because it is too complex and contains all possible workflow steps in it. It is recommended to use it only if you cannot use some of the other available base behaviours classes.

Item Page Navigation Behaviour Refactored

Now the behaviour accepts the required itemUrl as a constructor's parameter. The dependent ItemPage is resolved not in the BehavioursExecutor but rather in the behaviour itself through the help of the UnityContainerFactory class that provides the current instance of the Unity IoC container. The behaviour needs only to navigate to a single page because of that it implements the simple ActionBehaviour base class.

C#
public class ItemPageNavigationBehaviour : ActionBehaviour
{
    private readonly ItemPage itemPage;
    private readonly string itemUrl;

    public ItemPageNavigationBehaviour(string itemUrl)
    {
        this.itemPage = UnityContainerFactory.GetContainer().Resolve<ItemPage>();
        this.itemUrl = itemUrl;
    }

    protected override void PerformAct()
    {
        this.itemPage.Navigate(this.itemUrl);
    }
}

UnityContainerFactory

It is a static class that contains a single static method GetContainer that returns the current instance of the Unity IoC Container. It can be also implemented as a singleton.

C#
public static class UnityContainerFactory
{
    private static IUnityContainer unityContainer;

    static UnityContainerFactory()
    {
        unityContainer = new UnityContainer();
    }

    public static IUnityContainer GetContainer()
    {
        return unityContainer;
    }
}

SignIn Page Login Behaviour Refactored

The changes are almost identical to the ones applied to the ItemPageNavigationBehaviour except the class inherits WaitableActionBehaviour. It overrides the PerformPostActWait method where it waits for the shipping address page to load.

C#
public class SignInPageLoginBehaviour : WaitableActionBehaviour
{
    private readonly SignInPage signInPage;
    private readonly ShippingAddressPage shippingAddressPage;
    private readonly ClientLoginInfo clientLoginInfo;

    public SignInPageLoginBehaviour(ClientLoginInfo clientLoginInfo)
    {
        this.signInPage = 
        UnityContainerFactory.GetContainer().Resolve<SignInPage>();
        this.shippingAddressPage = 
        UnityContainerFactory.GetContainer().Resolve<ShippingAddressPage>(); 
        this.clientLoginInfo = clientLoginInfo;
    }

    protected override void PerformPostActWait()
    {
        this.shippingAddressPage.WaitForPageToLoad();
    }

    protected override void PerformAct()
    {
        this.signInPage.Login(this.clientLoginInfo.Email, this.clientLoginInfo.Password);
    }
}

Simplified BehaviourExecutor

The executor now doesn't hold any complex logic, it contains only a single Execute method that accepts an array of behaviours' workflows.

C#
public static class BehaviourExecutor
{
    public static void Execute(params IBehaviour[] behaviours)
    {
        foreach (var behaviour in behaviours)
        {
            behaviour.Execute();
        }
    }
}

Behaviours Design Pattern in Tests

C#
[TestMethod]
public void Purchase_SimpleBehaviourEngine()
{
    var itemUrl = "/Selenium-Testing-Cookbook-Gundecha-Unmesh/dp/1849515743";
    var itemPrice = "40.49";
    var clientPurchaseInfo = new ClientPurchaseInfo(
        new ClientAddressInfo()
        {
            FullName = "John Smith",
            Country = "United States",
            Address1 = "950 Avenue of the Americas",
            State = "New York",
            City = "New York City",
            Zip = "10001-2121",
            Phone = "00164644885569"
        });
    clientPurchaseInfo.CouponCode = "99PERDIS";
    var clientLoginInfo = new ClientLoginInfo()
    {
        Email = "g3984159@trbvm.com",
        Password = "ASDFG_12345"
    };
    BehaviourExecutor.Execute(
        new ItemPageNavigationBehaviour(itemUrl),
        new ItemPageBuyBehaviour(),
        new PreviewShoppingCartPageProceedBehaviour(),
        new SignInPageLoginBehaviour(clientLoginInfo),
        new ShippingAddressPageFillShippingBehaviour(clientPurchaseInfo),
        new ShippingAddressPageFillDifferentBillingBehaviour(clientPurchaseInfo),
        new ShippingAddressPageContinueBehaviour(),
        new ShippingPaymentPageContinueBehaviour(),
        new PlaceOrderPageAssertFinalAmountsBehaviour(itemPrice));
}

Compared to previous variations, you can notice few significant changes. First, you need to pass the behaviours through the new operator and pass any required parameters. Previously, you passed the behaviours via the typeof operator. You are no more obligated to initialise the static test context. I believe these changes made the tests much more flexible, readable and maintainable.

Design Patterns in Automated Testing

The post Advanced Behaviours Design Pattern in Automated Testing Part 1 appeared first on Automate The Planet.

All images are purchased from DepositPhotos.com and cannot be downloaded and used for free.
License Agreement

License

This article, along with any associated source code and files, is licensed under The Microsoft Public License (Ms-PL)


Written By
CEO Automate The Planet
Bulgaria Bulgaria
CTO and Co-founder of Automate The Planet Ltd, inventor of BELLATRIX Test Automation Framework, author of "Design Patterns for High-Quality Automated Tests: High-Quality Test Attributes and Best Practices" in C# and Java. Nowadays, he leads a team of passionate engineers helping companies succeed with their test automation. Additionally, he consults companies and leads automated testing trainings, writes books, and gives conference talks. You can find him on LinkedIn every day.

Comments and Discussions

 
GeneralNice Information, thanks Pin
Bhuvanesh Mohankumar16-May-16 0:19
Bhuvanesh Mohankumar16-May-16 0:19 
Worth

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.