Introduction

Iberia’s Test Automation project uses a combination of design patterns to create a robust and flexible structure for Intl Whitelabel application and supports multiple brands and countries.

This document aims to provide an detailed explanation of how it works.

Design Patterns

The main components and patterns used are:

1. Page Objects: Represent the real pages of the application. Page classes are abstract and define common behaviors through abstract methods and common actions through BaseActions.

2. Template Methods: Define the structure of test steps, allowing concrete subclasses to implement specific behaviors.

3. Base Components: Reusable components that represent parts of the page, such as login and signup forms, containing already implemented functions such as inputEmail, clickButton and etc

4. Strategy Pattern: Used to dynamically decide which implementation of a test step should be used based on environment variables (brand and country).

5. Factory Pattern: Implemented through SignUpStrategy, PageFactory, UserFactory, which acts as factory classes to create instances of specific strategies based on environment variables.

Architecture Execution

• Base Pages (BasePage, BaseLoginPage, BaseSignUpPage): Reusable components that represent parts of the page, such as login and signup forms, containing already implemented functions such as inputEmail, clickButton and etc. Define abstract methods that need to be implemented by concrete pages for each brand.

• Base Components (BaseLoginForm, BaseSignUpForm): Define template methods that are already implemented and can be reused.

• Concrete Pages (LoginPagePLK, LoginPageBK, SignUpPagePLK, SignUpPageBK): Implement the abstract methods defined in the base pages, adapting them to the specific needs of each brand.

• Concrete Components (LoginFormPLK, LoginFormBK, SignUpFormPLK, SignUpFormBK): Implement or extend specific functionalities for each brand.

• Strategy Factory (SignUpStrategy): Decides and instantiates the appropriate strategy to execute a test step (e.g., registerNewUser()) based on environment variables in cases where a brand has multiple implementations for different countries.

Positive Points

• Code Reusability: High reusability of code is maintained by base components and template methods in such a way that it does not keep any redundancy and the maintenance becomes easy.

• Flexibility: The Strategy Pattern supports the facility to change the application's behavior very smoothly with no duplication of code.

• Clarity and Organization: The clear separation between base pages, base components, and their concrete implementations makes the architecture clearer, much more organized, and understandable.

• Extensibility: New subclasses and strategies can easily be added for a new brand or country in no time at all, without any addition or modification in the existing code.

Negative Points

• Initial Complexity: A little more complex during the initial implementation, as a lot of abstract classes, template methods, and strategies would have to be put in place.

• Maintenance Overhead: It can be quite challenging to maintain, as any changes in the base classes or strategies may affect many concrete implementations.

• Performance: The use of dynamic strategies and factories might introduce some minor performance overheads, though generally quite negligible when compared to the benefits in terms of flexibility.

• Learning Curve: Since the architecture is complex and includes a large number of design patterns, developers may take some time to understand it.

Conclusion

Such architecture is highly modular and flexible, easily molded to fit any brand or country without much trouble. While the initial complexity may be hard to overcome and there is a higher overhead of maintenance, the reusability, clarity, organization inside the code, and extensibility make this surely a good choice for Intl Whitelabel, an application that have highly different customizations between each implementation.