Using Docker for Automation Testing: Guide of How to Run It

How to Use Docker Compose for Automated Testing

Many engineers have been confused when designing a method for isolated testing. Fortunately, today we have great infrastructure solutions, like using docker-compose for testing. The purpose of this article is to present an alternative approach for docker automated testing. The auto-testing will be done separately from the Demo, with the runner, namely gitlab.ci and docker-compose, acting as container builders. The article will show you how to carry out automated testing with docker based on my own experience.

Our guide will affect only a small part of the capabilities and docker automation and includes a brief overview of the course of stages and the operating principle for running a docker-compose test, as well as a summary of the benefits and drawbacks of this approach. Here is a brief summary of what we are going to go through in this article.

We would also like to add that if you still have questions about Docker for QA automation or if they already exist now, you can always contact our experts on Docker, who will explain and help you if necessary.

Pros of automated testing with docker:

• Provides isolated work (you can use the demo concurrently);
• Owns a database (optional);
• Stores artifacts;
• Builds the project and tests it independently/itself;
• Programming language doesn’t matter;
• Enables to store artifacts (screenshots, logs, etc.);
• Allows viewing logs;
• Allows using some steps as shell scripts.

Cons of docker automation testing:

• Takes a long time;
• Uses up a runner or requires a separate one;
• Dockerized application/ Dockerizes the application.

Three stages comprising the functioning of the approach:

1. Creating your own database (not a vital step; you can work with an empty database).
2. Directly creating a docker compose for auto testing, as we will be utilizing containers and DockerFile in this approach.
3. Creating a gitlab.ci file

All these statements and considerations will be overlooked in detail in the following paragraphs to give a better understanding of the topic.

Basics of how to use docker for automated testing

In practice, automation employs numerous methods for running autotests. With the assistance of one of them, tests are conducted on a computer/server/service, such as Jenkins or Gitlab CI, and the results are projected onto a demo. However, this disables access to the demo environment. Another option is to create a separate environment and use it to conduct auto-tests. While access to the environment will always be requested, the user or customer will not always have this option. However, there is another strategy that combines the advantages of the previous ones.

I am going to explain how to isolate Java and Selenium auto-tests. Other languages, such as JavaScript or Python (and even programming languages for IoT), as well as other libraries, can also be utilized in this approach which allows test automation using docker compose.

What to consider using docker for automated testing

Before we learn more about Docker in test automation, let’s find out what is it. Docker is a software platform that enables quick application development, testing, and deployment. Docker compose in this approach is used to manage multiple containers simultaneously; it also requires the most recent web tool, the GitLab Container Registry, a secure private registry for Docker images.

The primary advantages of the automated docker-compose test approach:

1. A working demo. When you run a pipeline that includes Demo or Production tests, you can perform further testing or make changes.
2. Using the same photos and services to our Demo/Production.
3. Ability to add artifact storage (screenshots or logs) and schedule automated docker compose test launches in GitLab.
4. Autonomy from the language in which tests are written or from the libraries utilized.
5. Using your own database, which enables you to connect tests to your own database, which is particularly useful if your application contains a large number of dynamic structures or tables that are interconnected.
6. Working with shell scripts is possible.

Despite its advantages, using docker for test automation has certain drawbacks:

1. Conducting testing consumes considerable effort and results in performance degradation. To begin, a project is created with a database, and tests are run in it.
2. You should have a dockerized project; otherwise, you must do it manually.
3. As with many other auto-testers who run their tests through a pipeline and utilize CI/CD, the tests require their own runner.

How to start docker compose test: three stages of the isolated approach

The process of developing an isolated approach is divided into three stages.

Step 1: Create your own database — in my case, I utilized MySQL. To start the docker compose test, you should build a database, dump it, and save it in the project’s root directory.

Use the dump and run the migrations as a separate script dbScript.sh:

#!/bin/bash
sleep 20
echo "connected to DB"
docker exec -i db mysql -h 127.0.0.1 -u root -pwebbylab webbylab < $(pwd)/etc/db/webbylab.sql

Step 2: Creating a Dockerfile to build an image:

FROM markhobson/maven-chrome:jdk-11

the image used in my case to run tests using Java

COPY . .

Next, you need to create docker compose.yml:

version: '3.7'
services:
 automation:
   image: gitlab.com:leshamalakhov/automationdocker
   container_name: automationTests
   command: mvn clean test -Dtest=TestingFile
   environment:
     URL: http://localhost:3000
app:
   image: hellrazers/app
   container_name: app
   restart: always
   environment:
       APP_DB_HOST: db
       APP_PORT: 3000
       APP_DB_PORT: 3306
       MYSQL_ROOT_PASSWORD: webbylab
       MYSQL_DATABASE: webbylab
       MYSQL_USER: webbylab
       MYSQL_PASSWORD: webbylab
   ports:
       - 3000:3000
   depends_on:
       - db
 
 
 db:
   image: mysql:5.7
   container_name: db
   expose:
     - 3306
   environment:
       MYSQL_ROOT_PASSWORD: webbylab
       MYSQL_DATABASE: webbylab
       MYSQL_USER: webbylab
       MYSQL_PASSWORD: webbylab

Depending on the project, docker compose can include other services.

Step 3: For GitLab authorization, you need to create separate commands in gitlab-ci; you can export these as a gitlabLogin.sh:

#!/usr/bin/env bash
 
docker login -u gitlab-ci-token -p "$CI_JOB_TOKEN" "$CI_REGISTRY"
docker build . -t gitlab.com:leshamalakhov/automationdocker
docker push gitlab.com:leshamalakhov/automationdocker

The last file to create is .gitlab-ci.yaml or Gitlab runner instructions:

image:ci-image //the image to build the project should be used here (if available)

//docker wrapper since Docker-in-Docker service is used

services:
 - docker:dind
 
cache:
 paths:
   - .m2/repository/
   - target/
 
stages:
 - test
 
test:
 stage: test
 script:
   - ./bin/gitlabScript.sh
   - docker-compose up -d app
   - ./bin/dbScript.sh
   - docker-compose run --rm automation
   - docker-compose down
 allow_failure: true

Conclusion

To sum up, we looked at an alternative approach in this article that allowed auto-tests to become a full-fledged standalone application without using the demo environment. Running docker compose test might require additional services dependencies. For example, to run tests, the app needs an accessible database instance. The Gitlab CI Service makes running tests easier to comprehend and set up on a daily basis. It includes “Schedules” functionality built in, which allows you to store artifacts like logs, screenshots, and so on. We also used Docker, making it very simple to install additional services such as Adminer, Graffana, or services that will be used in your project.