Lean Web Test Automation Architecture

This article belongs to a How to create Lean Test Automation Architecture for Web using Java libraries series.

Introduction

This is a series of articles showing how to create lean test automation architecture for web test automation using Java libraries.

Lean means that we will have as little code as possible to create reliable, maintainable, and useful architecture.

Architecture means the organization, features, and configurations that should be present to enable you to create automated scripts.

This first article will show you the basic explanation of the necessary elements to create lean architecture.

Basic Architecture

Clean architecture

Architecture is the overall design of the project. It organizes the code into different layers and defines how they will interact with each other.

In Clean architecture, you will organize the project to make it easy to understand and change as the project evolves.

There’s an excellent post by Uncle Bob about The Clean Architecture that will show you a proposed organization based on an application (not a test framework/architecture).

Design Patterns

You can use any design pattern to help you to better organize and maintain your code. There are some you can always use to achieve those benefits for a specific task.

Factory Method

You can use the Factory Method pattern to create browser instances because a better test architecture for web test automation should provide an easy mechanism to create them.

You can also use this design pattern to create a Data Factory.

Builder

You can use the Builder pattern to simplify the creation of the complex objects you have in your code, like:

• in the model classes, you will create to reuse the concrete entities
• in the page object, to make it easier to consume
• in the test data builder, to make the data creation easier

Singleton

You can use the Singleton pattern to reuse the same object instance among your tests, like:

• have shared access to the data of your configuration files
• share the same database connection (if you need it)

Testing Patterns

As for the Design Pattern, you can use some Testing Patterns that will show the same benefits.

Base Test

You can use the Base Test to reuse the same behavior in all your tests avoiding code duplication. The best example for web test automation is the pre and post-conditions you will always have: create the browser instance open it, and close it when the test finishes.

Test Data Factory

It combines the Object Mother and the Fluent Builder into a class to create data for your models. Imagine you have a Payment model wherein your test you will use it to approve or reject depending. The Test Data Factory will create different Payment objects based on the data, so you can have an amount that won’t be accepted during the approval process and another that will be accepted.

Page Object

You can use the Page Object pattern to enhance test maintenance and reduce code duplication modeling your pages into classes that will be the interface between the code and the UI.

Logs and Reports

Test code needs to be handled like your production code. You might face problems during the testing execution like:

• assertion errors
• elements not present in the UI
• timeout exceptions
• architecture-specific exceptions

You can add a logging strategy in your test architecture to easily, analyze, and understand the errors, so you can take action or have historical information about the problems.

You might need to inform your stakeholders about how reliable your application is, showing a user-friendly report that can show all the important metrics, as well as the testing evidence (like screenshots).
The report strategy is required even for you to quickly analyze the test results.

Data Generation

Generating data for the test is one of the most time-consuming actions, even for automated tests, but it is necessary.

We can apply, at least, three different approaches:

• Fake generation: this is the way we can generate non-sensitive data
• Static generation: is the way we can control the data through a data pool, like files (csv, yaml, txt, json, etc…)
• Dynamic generation: is the way we can generate sensitive data using an approach without any changes in our scripts

Parallel Execution

This is the most needed feature in a web test architecture today, We need to execute the test as fast as we can, and to speed up all the test execution, through a test suite, we need to use a grid infrastructure.

The first step is to either create a parallelization solution or use an existing one present in the testing library (like JUnit or TestNG).

The second step is to define an environmental solution. It can be either:

• local solution using bare metal that might not scale
• local solution using containers and auto-scale up and down it
• cloud solution to auto-scale up and down

Pipeline

The last item we need to create is the strategy to execute all the scripts. It will require first the definition of your regression testing execution where you will create test suites. Defining this strategy you can control when and where executing the test scripts.

The second part is the pipeline script that you should create dividing into stages to sequentially execute your test suites to get faster feedback on your application reliability.