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.
The article also 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.
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 automation testing with docker:
- 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:
- Creating your own database (not a vital step; you can work with an empty database).
- Directly creating a docker compose for auto testing, as we will be utilizing containers and DockerFile in this approach.
- 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.
What to consider using docker for automated testing
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 automated docker compose test approach:
- A working demo. When you run a pipeline that includes Demo or Production tests, you can perform further testing or make changes.
- Using the same photos and services to our Demo/Production.
- Ability to add artifact storage (screenshots or logs) and schedule automated docker compose test launches in GitLab.
- Autonomy from the language in which tests are written or from the libraries utilized.
- 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.
- Working with shell scripts is possible.
Despite its advantages, this approach has certain drawbacks:
- 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.
- You should have a dockerized project; otherwise, you must do it manually.
- 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:
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
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.
The main task was to implement engine for natural language recognition to develop artificial intelligence (AI) for conversational chatbot to be used by the insurance…
Each programmer must have come across the necessity to check user’s input a number of times. Having a 12-year experience in web development, I have…
“Flux Standard Action” has 3700+ stars on github and used by “redux-promise”, “redux-actions” and other libraries. Several weeks ago one of my developers tried to…