Facade Design Pattern — Automation Testing

What are design patterns:

Design patterns are blocks that help us to put out our project planning into efficient structures. For any automation testing framework, implementation of the correct design pattern is important to achieve code readability, reliability and maintainability.

Types of Design Patterns:

In Automation testing, commonly used design patterns are
1) Page object model

2) Factory design pattern

3) Facade Pattern

4) Singleton pattern

5) Fluent page object model

In this blog we will talk about Facade design pattern, which helps to implement complex and lengthy user actions with ease and reusability.

What is the Facade design pattern?

The Facade model comes under structural design patterns. It suggests the use of a simple interface to implement complex/lengthy code. When implemented in automation, we design a facade class which implements methods that combine actions which are executed on different pages using a page object model.

Let’s talk about Online shopping. As a customer, when I try to buy an item , I need to go through multiple pages to enter shipping address, billing address, payment information, review order & finally place order etc. As a customer, the only thing I see my order is getting placed with saved address and payment info and that is a Facade to me.

In automation, this design pattern can be seen and implemented as an extension to the page object model to create less lengthy, simpler and highly readable test cases.

We can understand the design by looking at the example below.

Here we have:

1. Page objects for different pages from application under test.
2. A facade class, which combines the actions from mentioned page objects.
3. Test classes, which will interact with facade only to get the action done on UI.

Why do we need Facade?

Increasing test automation coverage and complex applications under test can often result in lengthy and unmaintainable automation tests.

Example: Assume a number of test cases needs to perform a series of actions on multiple pages to get to a particular page from where the scope of test begins.

To Understand this, let’s take an example of an Online shopping experience where as a user, I want to verify and interact with my order history.

Implement without Using Facade Pattern:

The drawback from above piece of code is:

• Test becomes too lengthy
• If any additional page has been introduced in UI to reach the final page, then all the tests implementing this flow need to be updated.

e.g. In the example above, after clicking the order history link, if we need to perform some actions (e.g select the timeframe of placing the orders) before we can even navigate to another page then we will have to update both the tests, increasing lines of redundant code as well.

Implement Using Facade Pattern:

We can avoid this by using the Facade Model in our test automation framework. Being a QA engineer, I would be required to accommodate this change just in my facade class and all the tests implementing the flow will have effective changes.

Advantages of Facade design pattern:

• It provides an entry point needed to each level of layered user action.
• It increases the readability of code when complex actions are implemented.
• Tests will become simplified and short as we utilise facade classes for actions.
• As Facade is a structural design change, it can be easily integrated with any of the existing patterns and/or approaches like TDD, BDD etc.

To understand the advantages let’s consider another example of an Online shopping experience. As an end user I want to purchase an item and provide my feedback for overall shopping experience with the website.

Disadvantages of Facade:

• Adds an additional layer of indirection which may affect performance
• If for any system change, the structure of class is changed then the facade layer also needs to be updated.

Summary:

Use of design patterns, increase the effectiveness of code and automation. At the same time, it reduces the complexity and maintenance efforts. In the case of Facade pattern, the effort and efficiency can directly be correlated with LOC matrices.

For Example, for the order history scenario:

LOC without Facade ~ 17

LOC with Facade ~ 14

We were able to reduce the LOC by ~17% and in turn our maintenance effort will be less as well.

With the help of Facade pattern, we can combine complex implementation with multiple actions and provide a simple interface with the ease of access to achieve the same operation.