Test automation based on Ruby stack

Boilerplate can be found at Gitlab

So, first things first, please clone the repository. It includes all required tools, you can start writing tests at once. But, if you’re greedy for details, read on.

Dockerfile

I was not a fan of Docker technologies. I guess it’s because all my development was around Ruby language (standard MRI). And I had all versions installed on my computer. But, then my friend asked me to help him with some PHP. After 20 minutes of trying to install the correct version of the language and all libraries, I took Docker and configured everything there. From that point all my projects support Docker.

# Linux Alpine with installed the last version of ruby. At the moment of writing this article it's ruby 2.7
FROM ruby:alpine
 
# Setting your main working directory. If the directory does not exist it will be created.
WORKDIR /current
 
# Copying all your files (actually just Gemfile would be enough)
ADD . /current
 
# Adding required packages. Pay attention to chromium-chromedriver. Yes, further in Gemfile, we will use webdrivers gem, but this gem is not compatible with Linux Alpine. So, but still we will use them for debugging.
RUN apk add --update --no-cache \
	build-base \
	nodejs \
	chromium \
	libxml2-dev \
	libxslt-dev \
	chromium-chromedriver
 
# Hacky variable will be used to define which environment is launched.
ENV CURRENT_ENV=docker
 
# Installing ruby dependencies
RUN gem install bundler
RUN bundle config build.nokogiri --use-system-libraries
RUN bundle install

# Linux Alpine with installed the last version of ruby. At the moment of writing this article it's ruby 2.7

FROM ruby:alpine

# Setting your main working directory. If the directory does not exist it will be created.

WORKDIR /current

# Copying all your files (actually just Gemfile would be enough)

ADD . /current

# Adding required packages. Pay attention to chromium-chromedriver. Yes, further in Gemfile, we will use webdrivers gem, but this gem is not compatible with Linux Alpine. So, but still we will use them for debugging.

RUN apk add --update --no-cache \

build-base \

nodejs \

chromium \

libxml2-dev \

libxslt-dev \

chromium-chromedriver

# Hacky variable will be used to define which environment is launched.

ENV CURRENT_ENV=docker

# Installing ruby dependencies

RUN gem install bundler

RUN bundle config build.nokogiri --use-system-libraries

RUN bundle install

It’s all for Docker. Ping me if you know how to improve.

Ruby stack. Gems.

It’s time to speak about our ruby business. Here the list of libraries and their assignments:

capybara — what we call «sugar» or DSL over different drivers, like Selenium. Without capybara you can’t write something like visit ‘moduscreate.com’. But, if you wish you can write your own layer; it should be an interesting adventure.
cucumber — all things around BDD, like Gherkin language support e.t.c.
webdrivers — webdrivers gem will download the last version of chrome/firefox/edge driver if a certain version was not defined. In my case it didn’t play well with Alpine. After this article definitely i will sit and find out what’s the problem.
rspec — well known library for every ruby developer. Added to here in order to have these nice readable expectations.
byebug — it’s a debugger. Developing new tests I prefer to run browser in normal mode, stop tests when a certain page is opened and play with elements on the page.
site_prism — library which provides easy integration with the Page Object pattern. Using site_prism makes your tests easy to change, and decouples logic of tests from page

All required configurations for these libraries are in the features/support directory.

Gitlab CI

Next stop is Gitlab CI. Well as i said this boilerplate is quite opinionated. Last 4 years I have landed all my projects on Gitlab. And they were first (compared to Github) with CI/CD system. Even now when we have Github Actions I think Gitlab CI has far more features. But, I understand maybe it’s because Github Actions still is young.

So, as in case with Dockerfile I will explain all lines. Let’s dive in .gitlab-ci.yml.

# Yes at our CI system we will use Docker in Docker. It means as base image we need docker.
image: docker:19.03.12
 
services:
  # dind means Docker-in-Docker
  - docker:19.03.12-dind
 
before_script:
  # Variables predefined by Gitlab CI in order to use their Docker registry.
  - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
 
# There are two stages but building docker image is optional.
stages:
  - building docker image
  - running tests
 
# Building Docker image stage
Building docker image:
  stage: building docker image
  script:
    # Pulling image which will be used as cache
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    # Building new version of image
    - docker build --cache-from $CI_REGISTRY_IMAGE:latest --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .
  # Build new version only if Dockerfile or Gemfile has been changed
  only:
    changes:
      - Dockerfile
      - Gemfile
  # Saving image to Gitlab Docker Registry
  after_script:
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
 
# Running tests stage
Running tests:
  stage: running tests
  script:
    - docker pull $CI_REGISTRY_IMAGE:latest || true
    # Finally running tests
    - docker run --rm --volume $(pwd):/current $CI_REGISTRY_IMAGE:latest bundle exec cucumber
  artifacts:
    paths:
       # There is little helper which makes a screenshot every time when the test is failing.
      - screenshots
    when: always

# Yes at our CI system we will use Docker in Docker. It means as base image we need docker.

image: docker:19.03.12

services:

# dind means Docker-in-Docker

- docker:19.03.12-dind

before_script:

# Variables predefined by Gitlab CI in order to use their Docker registry.

- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

# There are two stages but building docker image is optional.

stages:

- building docker image

- running tests

# Building Docker image stage

Building docker image:

stage: building docker image

script:

# Pulling image which will be used as cache

- docker pull $CI_REGISTRY_IMAGE:latest || true

# Building new version of image

- docker build --cache-from $CI_REGISTRY_IMAGE:latest --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --tag $CI_REGISTRY_IMAGE:latest .

# Build new version only if Dockerfile or Gemfile has been changed

only:

changes:

- Dockerfile

- Gemfile

# Saving image to Gitlab Docker Registry

after_script:

- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

- docker push $CI_REGISTRY_IMAGE:latest

# Running tests stage

Running tests:

stage: running tests

script:

- docker pull $CI_REGISTRY_IMAGE:latest || true

# Finally running tests

- docker run --rm --volume $(pwd):/current $CI_REGISTRY_IMAGE:latest bundle exec cucumber

artifacts:

paths:

# There is little helper which makes a screenshot every time when the test is failing.

- screenshots

when: always

How can I use Gitlab CI, if I don’t even have a deploy process? Or you have another repository which is not connected with e2e tests. Here two examples:

If you don’t have a deployment process, you can configure the schedule for your e2e tests repository. For example every 2 hours.
If you have a deployment process. It’s even cooler, you may trigger your e2e tests repository example (read more about multi-project pipelines):

Remote test:
  stage: test
  trigger:
    project: path_to_your_repository_with_tests
    branch: master
    strategy: depend

Remote test:

stage: test

trigger:

project: path_to_your_repository_with_tests

branch: master

strategy: depend

Where are the tests?

So, all preparations are made. Now we can check out some examples in the features directory. There I test moduscreate.com to have some cool vacancies (we always have them). And sometimes there are test automations engineers vacancies.

How to use it?

Please check Readme at corresponding repository. Shortly speaking you can launch tests on Docker or on your host machine. Running tests locally you can view all actions visually in the browser, it helps to debug existing or create new tests.

Last words

I made this article because I use this boilerplate and wanted to share my thoughts. If you are a junior, you may find this template as a good starting point. You may hear “ruby is dead” i’ve been hearing this for the last 4-5 years. It’s not important which language you use, more important how good you are with it. Ok, I don’t know why I’m delaying you. Fork and try it out.