HOME

This tutorial explains the process to run the Cucumber Tests in the GitLab pipeline. This is a very important step towards achieving CI/CD.

Table of Contents

1. Prerequisite
2. What is GitLab CI/CD Workflow?
3. What is a headless browser?
4. Why do we use Headless browser for executing tests in CI/CD pipeline?
5. GitLab Section
   1. Create a blank project in GitLab
   2. Push the project from local repository to Gitlab Repository
   3. Create a .gitlab-ci.yml file in the project in GitLab
   4. Run the tests in the GitLab pipeline
   5. Check the status of the pipeline
   6. Download the report

Prerequisite:

What is GitLab CI/CD Workflow?

GitLab automatically enables CI/CD pipelines for new projects. It’s just a matter of adding a new configuration file called .gitlab-ci.yml to your code repository with instructions for GitLab on what to run. So simply create the following basic workflow in your main repository directory and commit it:

The Serenity tests run on a headless browser in the pipeline.

What is a headless browser?

A headless browser is a web browser that operates without a graphical user interface (GUI). It is typically used for automated testing, web scraping, and server-side rendering of web pages. While traditional web browsers like Chrome, Firefox, or Safari have a visible interface for users to interact with, headless browsers work in the background and don’t display the web content visually.

Why do we use Headless browser for executing tests in CI/CD pipeline?

Headless browsers provide a consistent and controlled environment for running tests. They eliminate the variability introduced by different operating systems, browser versions, or screen resolutions, ensuring that tests produce consistent and reliable results across different environments.

Headless browsers can often execute tasks faster than their graphical counterparts. They don’t need to render and display web content, which can significantly reduce the execution time for automated tests or other web-related tasks, contributing to faster feedback in the CI/CD pipeline.

In the below example, our tests are in headless mode.

WebDriverManager.chromedriver().setup();
ChromeOptions ops = new ChromeOptions().setHeadless(true);
ops.addArguments("--remote-allow-origins=*");
driver = new ChromeDriver(ops);

To get the Cucumber Framework with MasterThoughts Report with TestNG, please refer to this tutorial – Implemention of ‘Masterthought’ Reports in Cucumber with TestNG.

GitLab Section

Step 1 – Create a blank project in GitLab

To know, how to create a blank new project in GitLab, please refer to this tutorial.

Step 2 – Push the project from local repository to Gitlab Repository

To know, how to push the changes in GitLab, please refer to this tutorial.

Step 3 – Create a .gitlab-ci.yml file in the project in GitLab

There are many ways to create a new file in GitLab. One of the ways is to create a file as shown in the below image.

It is a YAML file where you configure specific instructions for GitLab CI/CD. In the .gitlab-ci.yml, we can define:

Below is a sample example to run the Cucumber tests in the GitLab pipeline.

image: markhobson/maven-chrome
 
stages:
  - test
 
variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
 
test:
  stage: test
  allow_failure: true
 
# Run the tests  
  script:
    - echo "Executing BDD scenarios with maven"
    - mvn clean test
 
# Store artifacts
  artifacts:
    when: always
    name: "Cucumber Report"
    paths:
    - target/*
    expire_in: 24 h

Image – markhobson/maven-chrome is used in this test. It is a docker image for Java automated UI tests.

Pipeline configuration begins with jobs. Jobs are the most fundamental element of a  .gitlab-ci.yml file.

Jobs are:

• Defined with constraints stating under what conditions they should be executed.
• Top-level elements with an arbitrary name must contain at least the script clause.
• Not limited in how many can be defined.

Jobs can output an archive of files and directories. This output is known as a job artifact. The expire_in keyword determines how long GitLab keeps the job artifacts. Here, it shows 24 hrs to retain the artifacts.

Step 4 – Run the tests in the GitLab pipeline

Now, when a new change is committed, a pipeline kicks off and it runs all the tests.

Step 5 – Check the status of the pipeline

Once the Status of the pipeline changes to either failed or passed.. that means the tests are already executed.

As you can see the Status is passed, it’s green colour. This means all the tests present in the test suite are executed and passed. If any test fails in the test suite, the final execution status will be brown. The reason for the brown colour is we have mentioned allow_failure: true.

Below shows the execution status report in the GitLab pipeline.

As I have added an artifact also in the .gitalb-ci.yml, which is highlighted in the image. This artifact creates a folder with the name “Cucumber_Report” and the reports in this folder come from the path /target/site. This artifact gives us the option to download the reports or browse the report. This report will be available for 24 hours only as mentioned in the gitlab-ci.yml.

Step 5 – Download the report

Once, will click on the download button, it will download “Cucumber_Report.zip”. Unzip the folder and it looks like something as shown below:

Example of Overview Features

Example of Overview Tags

Example of Overview Steps

Congratulations. This tutorial has explained the steps to run Cucumber tests in GitLab CI/CD. Happy Learning!!