In my series of articles “Design Patterns in Automated Testing“, I am presenting you the most useful techniques for structuring the code of the automation tests. The today’s publication is going to be about the Facade Design Pattern. In my two previous posts, I have explained how to use the most famous pattern- Page Object Pattern. The Facade Design Pattern can bring even more abstraction over the page objects, so if you are not familiar with them, I advise you to read my articles on the matter.



Definition Make a software library easier to use, understand and more readable.

Reduce dependencies of outside code.

Keeps the Principle of least knowledge.

Wrap a poorly designed APIs in a better one. An object that provides a simplified interface to a larger body of code, such as class library.

UML Class Diagram

Participants

The classes and objects participating in this pattern are:

Facade – Holds methods that combine actions executed on multiple pages.

– Holds methods that combine actions executed on multiple pages. Page Objects (ItemPage)- Holds the actions that can be performed on the page like Search and Navigate. Exposes an easy access to the Page Validator though the Validate () method. The best implementations of the pattern hide the usage of the Element Map, wrapping it through all action methods.

(ItemPage)- Holds the actions that can be performed on the page like Search and Navigate. Exposes an easy access to the Page Validator though the () method. The best implementations of the pattern hide the usage of the wrapping it through all action methods. UI Tests (EbayPurchaseTests) – This class contains a group of tests related to the above facade; it can hold only a single instance of the facade.

Facade Design Pattern C# Code

Test’s Test Case

The primary goal of the below tests is going to be to purchase different items from Ebay. They need to make sure that the correct prices are displayed on the different pages.

1. Navigate to Item’s Page

2. Validate the price

3. Click Buy It Now button

4. On the SignIn page, click Continue as a guest

5. Fill Shipping Info

6. Validate Subtotal price

7. Click Continue button

8. Validate Total price

The primary goal of the design of the test classes is going to be to enable us to reuse the code for all different test cases. For example, purchasing different items with а different combination of shipping data, thus different total and subtotal prices.

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

Facade Design Pattern C# Code

The following class structure is going to be used.

There is nothing unusual in the most of the page objects. Probably, the most interesting logic is located in the ShippingAddressPage.

There are two public methods. The FillShippingInfo uses the data class ClientInfo to fill in the current client’s info.

The ClientInfo class holds only string properties.

Before the engine can start typing the information, the shipping frame should be switched to first. Otherwise, our test is going to fail. This logic is located in the ShippingAddressMap class.

In order the switch frame command to be successful, a wait operation is performed. The logo of the page is located outside of the frame, so its waiting guarantees that the page is completely loaded.

Tests without Facade Design Pattern

If we desire to perform two different tests- buy two separate products with varying information. We can perform them only with the above classes without a Facade class.

As you can see, the main problem in the examples is that we need to create instances of our pages for every test. Moreover, the whole workflow of the tests as method calls is copied. Practices mentioned above make our tests much harder to maintain. Also, it brakes one of the most important programming principles- DRY (Don’t-Repeat-Yourself).

Tests Using Facade Design Pattern

The solution of the above problems is to encapsulate our test’s logic/workflow in a Facade class.

In case the workflow of the test case is changed, it can be quickly updated only in a single place. Or if you want to add additional validations, they can be added to the PurchaseItem method.

Find below the code of the same tests refactored to use the Facade Design Pattern.