Test Automation - How To Create an Independent Automation Infrastructure using GitHub Actions

‍

Introduction

In this article, I will explain how to build an independent automation infrastructure using GitHub actions.

This article uses Java to describe the architecture process on other coding languages module and project might have different meanings for example on C# module equals to project and project equals to solution.

Let's explore 3 approaches to creating an automation infrastructure:

Infrastructure And Tests Are In The Same Module In The Same Project

This is the most simple and straightforward approach, it basically means there is no separation of concerns between our automated tests and our automation infrastructure. The division might be to different packages or classes or it might not be at all. This fits for small automation projects that focus only on a single domain (e.g only UI or Mobile) and only a single platform (e.g a single entry point to the application under test).

PROS:

• This is the fastest way to start your automation project.

CONS:

• It will be harder to scale up if more requirements arise and we stay with this approach.
• Every developer on the project can modify the infrastructure.
• It will impossible to share the infrastructure with other testing teams because everything is coupled together.

When more requirements for tests arise we will probably need to go with the second approach:

Infrastructure And Tests Are In The Different Modules In The Same Project

In the following approach, our automation infrastructure lives in its unique module. Other modules consume it and might represent domains we want to test (e.g Web/Mobile/API) or multiple applications under test. This approach is best suited when the automation serves a single team of engineers.

PROS:

• It enables decoupling our infrastructure from our tests.

CONS:

• Every developer on the project can modify the infrastructure.
• Won't fit when working with multiple automation development teams.

When dealing with a very large and diverse team of automation engineers with different coding skills and a vast amount of requirements from the automation infrastructure we might want to go with the third approach:

Infrastructure And Tests Are In Different  Project

In this approach, our automation infrastructure is hosted in its own repository. multiple automation projects consume it. Every change can affect the consumers - so the infrastructure itself becomes a product of the testing realm. The infrastructure is probably written by infrastructure automation developers/automation architects who only develop and maintain the infrastructure and don't actually write test cases.

PROS:

• It enables decoupling our infrastructure from our tests.
• Only privileged developers can modify the infrastructure.

CONS:

• This is the slowest way to start our automation project and requires dedicated efforts to maintain a separate project.

After covering the theoretical aspects let's dive into the technical details of implementing the last approach:

The technological stack used to implement the solution is:

Programing language: Java

Build tool: Maven

link to the project.

What is Github Actions?

according to this article:

GitHub Actions is an API for cause and effect on GitHub: orchestrate any workflow, based on any event, while GitHub manages the execution, provides rich feedback, and secures every step along the way. With GitHub Actions, workflows and steps are just code in a repository, so you can create, share, reuse, and fork your software development practices.

GitHub actions is free and support public repositories. the article will be demonstrated using my public repository which contains a single static method that is just saying hello :)

Implementing the Solution

We need to create a ".github" folder into the root of our project, inside it create a workflow folder. Inside it, we create our workflows which are YAML files.

This is the workflow content:

Walkthrough

We are running the workflow after a release is created

It runs the build on an Ubuntu instance provided by GitHub, here is the specification for Github hosted runners. Of course, there is also an option of creating custom runners. this workflow is pretty simple so I used a hosted runner.

now a series of workflow steps are executed in order:

• Checking out the latest code with the following action:

• Installing JDK version 8 with the following action:

• The last step in the workflow pushes the package to GitHub packages with the following action:

please notice we are using our GitHub token as an environment variable in order for this step to work.

our pom.xml file contains a special tag called "distributionManagement" which pinpoints to our repository

after all of this is set we can continue our work on the automation infrastructure, once we are ready we simply go to the release tab and create a new release

this will automatically trigger the workflow - once the build passed successfully a new package will be created.

we will need to update our local settings.xml file located in the .m2 folder with our repository URL our GitHub user name and a personal token which we need to create

now on other testing projects, we can use the automation infrastructure package as a dependency in the pom.xml file:

and use the "sayHello" method to get a greeting from the infrastructure project :)

In conclusion

In this article, we reviewed the creation of an independent automation infrastructure using GitHub actions Java and Maven. Some notable alternatives to implementing this solution for Java are JFrog Artifactory and Nexus server.

Further reading on GitHub actions features can be found in this link.

Happy testing!

‍