Slaying the Leviathan: Containerized Execution of Test Automation-part 1

Introduction

In this three-part series on test automation, I will explain how to utilize Docker, a Ruby/Cucumber web framework, and Jenkins to run parallel test automation within Docker containers.

All of the code shown in this series is accessible on GitHub here. This repository contains all Docker and Test Automation components necessary to follow along and complete the same steps on your machine. If you plan on following along, you will need to install Docker, Jenkins, Git, and Ruby

After you’ve installed the necessary prerequisites, go ahead and pull down the suite from GitHub. Navigate to the directory in the terminal where you want this framework to reside and run the command: ‘git clone https://github.com/jerren1122/docker_web_repo.git‘

If the command executes correctly, you should now have the docker_web_repo pulled down onto your local machine. In order for the later functionality to work I would ensure that the root folder of the framework has the name sample_cucumber.

Framework Introduction

Before we start with Docker, it’s important to understand how the framework functions when running locally. Completing the following steps provides a level of insight into the steps/components necessary for the framework to run.

• Step one has completed as we have cloned the repo from GitHub.
• Navigate to your terminal and type in ‘ruby -v‘, which returns the version number of Ruby installed on your machine. If it doesn’t, the Path environment variable needs to be updated to include the location of the Ruby executable. I am running Ruby 2.6.6, my path to the Ruby executable would be C:\Ruby26\bin.
• In the terminal, navigate to the directory where you pulled down the docker_web_repo, type in ‘gem install bundler‘, allowing you to utilize bundler’s ability to install all the gems listed in the Gemfile of the repo.

• Now input ‘bundle install‘ which pulls all the gems listed in the Gemfile down from https://rubygems.org.

• Navigate here and download the ChromeDriver of the same version number as Chrome on your machine.

• Once the ChromeDriver has been downloaded, place it in the bin directory of the version of Ruby you installed.

• This suite utilizes Rake tasks to run, for more information about Rake tasks click here. For this blog post, all you have to do is set an environment variable and run the Rake task. First, input ‘set or_tags=regression‘ into your terminal and then type ‘rake features:default‘. You will should see the output that the regression is running. No browser will visibly open because the suite is running in headless Chrome.

We now have a checklist of the environmental setup to be completed for this web repository to execute automated tests. 

Additional Functionality

Another powerful facet of this framework is the code in lib/utilities/dynamic_tags.rb. This code allowed the tests in the suite to be split into sections and ran in parallel. All this code required at runtime is for environment variables set for total_number_of_builds and build_number. 

This code worked by replacing a tag (by default @regression) with the tag @split_builds for a subset of the tests corresponding to the build_number provided as an environment variable.

Docker 101

The best overview is provided by the folks at Docker here. For our purposes, it’s important to understand the following.

At a high level, Docker allows for multiple processes to run on a single host. Each processes have a unique Host name, IP address and File System. Shared between them are the Hosts Operating System, CPU, and Memory. This is very similar to what a Virtual Machine is; however, one difference is that Virtual Machines have their own operating system.

Additionally, Docker offers methods of storing and deploying these processes. All of the setup necessary to run a process is stored as a Docker image. The Docker image is a snapshot of what you want the environment to look like for the process to run successfully.

The Docker image is constructed, utilizing a set of steps, housed within a Dockerfile.

Lastly, when we deploy a running instance of these images, which we call a “container” in the Docker world.

Conclusion and Next Steps

In this first blogpost of a three-part series, we executed the framework locally on our machine and became familiar with some of the components in the framework. Additionally, we have explored what Docker is, conceptually.

In the next blogpost, we dive into the actual implementation of Docker and how it interacts with the testing framework.

Series Navigation