Clean GUI Automation Test Framework

Challenges in Conventional GUI Automation Test Frameworks

Still a Monolith

Only conceptual segregation between Page Objects and rest of the framework. This still creates a monolith design in the long run, as the new team members, or sometimes entirely new team, joins the project and keep adding code as per their own understanding. This type of frameworks end up not keeping up with the organisational evolution and get replaced by a new one, which again gets through the same cycle. This becomes an intangible source of resource sink and difficult for any organisation to realise this.

Limited SOLID Design Principles 

The conventional way of code structuring do adhere to few of the SOLID design principles, but it loses its usefulness because of the lack of their application consistently and continuously at all the levels and stages of the development.

Granularity of Decoupling

Decoupling is limited only at the conceptual level between page objects and rest of the framework, i.e. just between business level and technical level. That too gets lost in the long run.  For a really flexible and agile solution, the decoupling should penetrate to the lowest level.

Goals of the Clean GUI Automation Test Framework

Future Proof 

The clean designed framework can accommodate any future requirements, conventions, operations, deployment and maintenance strategies.

Ease of Development

Any new change should affect least number of modules

Architecture

Below is the visual representation of this framework. Each of the blocks in this are pluggable i.e. they can be replaced by any implementations at any point of time.

Working Mechanism

 

Disambiguation

Driver : In general the word “Driver” in GUI automation refers to the wrapper of the automation tool like WebDriver, ChromeDriver, AppiumDriver, etc. We differ in meaning of this word in our framework. Instead of using this word to refer to the wrapper implementations for the automation tool, we use it in the root sense of the word and imply “driver of action”. Hence, for this framework it means “Driver of action using an Actor”. You will encounter code where the driver types of the automation tool will be used in the implementations of abstract type Actor, so this difference in meaning needs to be remembered.

Details of Design

Contract

Following the Liskov Substitution Principle (LSP) from the SOLID principles, everything in our design will be driven by contracts, hence this is the first component to design. Here is the UML for the contracts.

Technical Level Differentiations

Here we are showing the Selenium based implementations which further gets specialised into Chrome based implementations for the Chrome browser. In the similar way, this can be extended for any other browsers or tools (like Appium for mobile platforms).

Business Level Differentiation - Steps

Steps here is defined as a set of actions performed on a set of GUI elements. Since steps are affected by the business domain, it makes good sense to differentiate it based on the domain. Below is an example taking Google Search as our business domain.

Business Level Differentiation - Pages

Pages in an application are completely in the business domain. Below is an example for the Google Search pages.

Business Level Differentiation - Scenarios

Scenarios are completely business driven and hence need to be differentiated at business level. Below is the Google Search scenario UML.

Action Interceptor

In this framework we also added an interceptor for any Actor implementations for the purpose of statistics collection. This feature is handy for gathering performance metrics while doing GUI validations. To demonstrate its usage, the current implementation simply captures execution time for each action defined in the Actor interface. Since this also need to be decoupled from the actual implementations of the Actor interface, this is done by using dynamic proxy mechanism in Java.

Below is the conceptual representation of the workflow using the dynamic proxy

Running the Code

Prerequisites

• Chrome browser should be installed (Version 83.x.xxxx.xxx)
• Java 8 or above
• Maven3

Steps:

• Clone the repo https://github.com/priyeshkpandey/clean-data-structures.
• Move inside the cloned repo using command line interface
• Move inside the gui-framework folder
• Build the code using mvn clean install command
• Run the example Google Search using the command mvn -o exec:java

For your own implementations, please fork and raise PR