How to run Chrome tests in headless mode in Selenium

HOME

This tutorial explains the steps to run the Selenium tests for Chrome browser in headless mode. We are going to run the tests in Selenium 4 as well as Selenium 3.

What is headless browser?

A headless browser is like any other browser, but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we could not see the browser, but we can see the test results coming on the console.

Headless browser testing is generally faster when compared to actual UI testing as it doesn’t wait for the whole page to render before performing any action.

When we need to execute automated test cases remotely on a server or in any of the build and release pipelines for continuous integration servers like Gitlab or Jenkins, it is not always possible to install real browsers on such remote machines. We can use headless browsers to run automation tests efficiently.

It is easy to perform multi-tasking with a Headless browser. The browser or our machine can do anything else while the tests run in the background.

There are 2 ways to add dependencies to the Selenium project.

Download Selenium Version from here (Selenium 3 & Selenium 4)

Download ChromeDriver Binary (Selenium 3 only)

Download the latest version of WebDriverManager (Selenium 3 only)

Once the Selenium and WebDriverManager folders are downloaded, unzip the folder. Once the zip file is extracted, reference these jar files in the project. For this, navigate to project properties and click Build Path-> Configure Build Path in Eclipse. Click “Add External Jars“. After clicking on the “Add External JARs“, selected all the extracted JARs. The JARs files are present in the project.

2. Add the below dependencies to pom.xml or build.gradle.

Add below dependencies to the project.

 <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-java</artifactId>
      <version>4.16.1</version>
 </dependency>

package com.example.steps;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxOptions;

public class ChromeOptionsHeadless_Demo {

    public static void main(String[] args) {

        // Create an object of Chrome Options class
        ChromeOptions options = new ChromeOptions();

        // Set Firefox Headless mode as TRUE
        options.addArguments("--headless=new");

        // Create an object of WebDriver class and pass the Chrome Options object
        // as an argument
        WebDriver driver = new ChromeDriver(options);

        // Navigate to site url
        driver.get("https://duckduckgo.com/");

        System.out.println("Executing Chrome Driver in Headless mode..");
        System.out.println("Page Title : " + driver.getTitle());
        System.out.println("Page URL  : " + driver.getCurrentUrl());

        // Close the driver
        driver.quit();
    }

}

Add below dependencies to the project.

 <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-java</artifactId>
      <version>3.141.59</version>
 </dependency>

We know that to execute Selenium automation scripts on browsers like chrome or firefox, we must download the binary files of these drivers like chromedriver and geckodriver, etc. After this, we need to set the path to these binaries in the automation script or add the classpath location. Here, we want to execute Selenium WebDriver automation scripts on the Chrome browser, then you need first to download chromedriver.exe and then use the System.setProperty  method to set its path as follows:

	// Set the path of ChromeDriver
	System.setProperty("webdriver.chrome.driver",
				"C:\\Users\\Vibha\\Software\\chromedriver_win32_98.0.4758.102\\chromedriver.exe");

The complete program looks like as shown below:

import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

public class ChromeOptionsHeadless1 {

	public static void main(String[] args) {

		// Set the path of ChromeDriver
		System.setProperty("webdriver.chrome.driver",
				"C:\\Users\\Vibha\\Software\\chromedriver_win32_98.0.4758.102\\chromedriver.exe");

		// Create an object of Chrome Options class
		ChromeOptions options = new ChromeOptions();

		// pass the argument –headless to Chrome Options class.
		options.addArguments("--headless");

		// Create an object of Chrome Driver class and pass the Chrome Options object as
		// an argument
		ChromeDriver driver = new ChromeDriver(options);

		System.out.println("Executing Chrome Driver in Headless mode..");
		driver.get("https://duckduckgo.com/");

		System.out.println("Title of Page :" + driver.getTitle());
		System.out.println("Page URL  : " + driver.getCurrentUrl());

		// Close the driver
		driver.close();

	}
}

How to run headless Chrome Tests in Selenium using WebDriverManager?

WebDriverManager

<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.1.0</version>
</dependency>

WebDriverManager has an automated way to download browser executables(exes) or binaries. It supports different browsers like Chrome, Firefox, Microsoft Edge, Internet Explorer, Opera, or PhantomJS.

WebDriverManager.chromedriver().setup: checks for the latest version of the specified WebDriver binary. If the binaries are not present on the machine, then it will download the WebDriver binaries. Next, it instantiates the Selenium WebDriver instance with the ChromeDriver.

import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

import io.github.bonigarcia.wdm.WebDriverManager;

public class ChromeOptionsHeadless2 {

	public static void main(String[] args) {

		// WebDriverManager downloads chrome browser executables or binaries.
		WebDriverManager.chromedriver().setup();

		// Create an object of Chrome Options class
		ChromeOptions options = new ChromeOptions();

		// pass the argument –headless to Chrome Options class.
		options.addArguments("--headless");

		// Create an object of Chrome Driver class and pass the Chrome Options object as
		// an argument
		ChromeDriver driver = new ChromeDriver(options);

		System.out.println("Executing Chrome Driver in Headless mode..");
		driver.get("https://duckduckgo.com/");

		System.out.println("Title of Page :" + driver.getTitle());
		System.out.println("Page URL  : " + driver.getCurrentUrl());

		// Close the driver
		driver.close();

	}

}

Congratulations!! We are able to run Chrome tests in Selenium in headless mode.

How to run Firefox tests in headless mode in Selenium

HOME

This tutorial explains the steps to run the Selenium tests on Firefox browser in headless mode. We are going to run the tests in Selenium. To run the Selenium tests on Chrome browser in headless mode, refer this tutorial.

To start with, we need to add dependencies to the project.

Manually add the dependencies to the project

Download Selenium Version from here

Download Firefox Binary from here

Download the latest version of WebDriverManager (Download this if you want to use WebDriverManager to download browser executables(exes) or binaries automatically, then skip downloading FireFox Binary).

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.16.1</version>
</dependency>

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxOptions;

public class FirefoxOptionsHeadless_Demo {

    public static void main(String[] args) {

        // Create an object of Firefox Options class
        FirefoxOptions options = new FirefoxOptions();

        // Set Firefox Headless mode as TRUE
        options.addArguments("-headless");

        // Create an object of WebDriver class and pass the Firefox Options object
        // as an argument
        WebDriver driver = new FirefoxDriver(options);

        // Navigate to site url
        driver.get("https://duckduckgo.com/");

        System.out.println("Executing Firefox Driver in Headless mode..");
        System.out.println("Page Title : " + driver.getTitle());
        System.out.println("Page URL  : " + driver.getCurrentUrl());

        // Close the driver
        driver.quit();
    }

}

Add the below dependencies to pom.xml or build.gradle.

<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-java</artifactId>
      <version>3.141.59</version>
    </dependency>

What is headless browser?

A headless browser is like any other browser, but without a GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we could not see the browser, but we can see the test results coming on the console. This makes the test execution faster than normal execution. This is suitable for parallel testing as UI tests needs a lot of memory and resources.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxOptions;

public class FirefoxOptionsHeadless1 {

	public static void main(String[] args) {

		// Set the path of GeckoDriver
		System.setProperty("webdriver.gecko.driver",
				"C:\\Users\\Vibha\\Software\\geckodriver\\geckodriver.exe");

		// Create an object of Firefox Options class
		FirefoxOptions options = new FirefoxOptions();

		// Set Firefox Headless mode as TRUE
		options.setHeadless(true);

		// Create an object of WebDriver class and pass the Firefox Options object
		// as an argument
		WebDriver driver = new FirefoxDriver(options);

		// Navigate to site url
		driver.get("https://duckduckgo.com/");

		System.out.println("Executing Firefox Driver in Headless mode..");
		System.out.println("Page Title : " + driver.getTitle());
		System.out.println("Page URL  : " + driver.getCurrentUrl());

		// Close the driver
		driver.close();
	}
}

How to run headless Firefox Tests in Selenium using WebDriverManager?

WebDriverManager

<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.1.0</version>
</dependency>

WebDriverManager.firefoxdriver().setup(): checks for the latest version of the specified WebDriver binary. If the binaries are not present on the machine, then it will download the WebDriver binaries. In this case, it is not needed to download Firefox binary and set up the path

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxOptions;

import io.github.bonigarcia.wdm.WebDriverManager;

public class FirefoxOptionsHeadless2 {

	public static void main(String[] args) {

		WebDriverManager.firefoxdriver().setup();

		// Create an object of Firefox Options class
		FirefoxOptions options = new FirefoxOptions();

		// Set Firefox Headless mode as TRUE
		options.setHeadless(true);

		// Create an object of Firefox Driver class and pass the Firefox Options object
		// as an argument
		WebDriver driver = new FirefoxDriver(options);

		// Navigate to the url
		driver.get("https://duckduckgo.com/");

		System.out.println("Executing Firefox Driver in Headless mode..");
		System.out.println("Page Title : " + driver.getTitle());
		System.out.println("Page URL  : " + driver.getCurrentUrl());

		// Close the driver
		driver.close();
	}

}

Congratulations!! We have run the tests in headless mode in FireFox.

How to run Edge tests in headless mode in Selenium4

HOME

This tutorial explains the steps to run the Selenium tests for Microsoft Edge in headless mode. We are going to run the tests in Selenium 4.

There are 2 ways to add dependencies to the Selenium project.

Manually add the dependencies to the project

Download Selenium Version from here

Download Microsoft Edge Binary from here

Download the latest version of WebDriverManager

Once the Selenium and WebDriverManager folders are downloaded, unzip the folder. Once the zip file is extracted, reference these jar files in the project. For this, navigate to project properties and click Build Path-> Configure Build Path in Eclipse. Click “Add External Jars“. After clicking on “Add External JARs“, selected all the extracted JARs. The JARs files are present in the project.

Add the below dependencies to pom.xml or build.gradle

Selenium 4

 <!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.1.2</version>
</dependency>

What is a headless browser?

A headless browser is like any other browser but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we could not see the browser, but we can see the test results coming on the console.

We know that to execute Selenium automation scripts on browsers like edge, we must download the binary files of the EDGE driver – msedgedriver. After this, we need to set the path to these binaries in the automation script or add the classpath location. Here, we want to execute Selenium WebDriver automation scripts on the Microsoft Edge browser, then you need first to download msedgedriver.exe and then use the System.setProperty  method to set its path as follows:

		// Set the path of EdgeDriver
		System.setProperty("webdriver.edge.driver",
				"C:\\Users\\Vibha\\Software\\edgedriver_win64\\msedgedriver.exe");

The complete program looks like as shown below:

import org.openqa.selenium.edge.EdgeDriver;
import org.openqa.selenium.edge.EdgeOptions;

public class EdgeHeadlessInSelenium4 {

	public static void main(String[] args) {
		// Set the path of EdgeDriver
		System.setProperty("webdriver.edge.driver",
				"C:\\Users\\Vibha\\Software\\edgedriver_win64\\msedgedriver.exe");

		// Create an object of Edge Options class
		EdgeOptions edgeOptions = new EdgeOptions();

		// pass the argument –headless to Edge Options class.
		edgeOptions.addArguments("--headless");

		// Create an object of WebDriver class and pass the Edge Options object as
		// an argument
		WebDriver driver = new EdgeDriver(edgeOptions);

		System.out.println("Executing Edge Driver in Headless mode..");
		driver.get("https://duckduckgo.com/");

		System.out.println("Title of Page :" + driver.getTitle());
		System.out.println("Page URL  : " + driver.getCurrentUrl());

		// Close the driver
		driver.close();

	}

}

How to run headless Microsoft Edge Tests in Selenium using WebDriverManager?

WebDriverManager Maven Dependency

<!-- https://mvnrepository.com/artifact/io.github.bonigarcia/webdrivermanager -->
<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.1.0</version>
</dependency>

WebDriverManager has an automated way to download browser executables(exes) or binaries. It supports different browsers like Chrome, Firefox, Microsoft Edge, Internet Explorer, Opera, or PhantomJS.

WebDriverManager.edgedriver().setup: checks for the latest version of the specified WebDriver binary. If the binaries are not present on the machine, then it will download the WebDriver binaries. Next, it instantiates the Selenium WebDriver instance with the EdgeDriver.

import org.openqa.selenium.edge.EdgeDriver;
import org.openqa.selenium.edge.EdgeOptions;

import io.github.bonigarcia.wdm.WebDriverManager;

public class EdgeHeadlessWithWebDriverManagerInSelenium4 {

	public static void main(String[] args) {

		// Create an object of Edge Options class
		EdgeOptions edgeOptions = new EdgeOptions();

		// pass the argument –headless to Edge Options class.
		edgeOptions.addArguments("--headless");

		// Create an object of WebDriver class and pass the Edge Options object as
		// an argument
		WebDriver driver = new EdgeDriver(edgeOptions);

		System.out.println("Executing Edge Driver in Headless mode..");

		driver.get("https://www.bing.com/");
		System.out.println("Title of Page :" + driver.getTitle());
		System.out.println("Page URL : " + driver.getCurrentUrl());

		// Close the driver
		driver.close();

	}
}

Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!! Cheers!!

Basic Selenium Tutorials

HOME

Selenium – Introduction, Installation, Test Script

Chapter 1 Introduction to Selenium Automation Tool
Chapter 2 How to Download & Install Java JDK 11 in Windows
Chapter 3 How to Download and Install Eclipse IDE
Chapter 4 How to install IntelliJ on Windows
Chapter 5 How to Download & Install Selenium WebDriver 
Chapter 6  How to create first Selenium WebDriver Script using Java
Chapter 7 How to run Selenium Tests using on Internet Explorer

Locators in Selenium

 Chapter 1 How to Locate Elements in Chrome, Firefox and IE Browsers for creating Selenium Scripts
Chapter 2 Locators in Selenium – Locate by ID, ClassName,  Name, TagName,  LinkText, PartialLinkText
Chapter 3 Dynamic XPath  in Selenium WebDriver
Chapter 4 CSS Selector in Selenium WebDriver

Launching Browsers and headless Browser

Chapter 1 How to run Chrome tests in headless mode in Selenium
Chapter 2 How to run Firefox tests in headless mode in Selenium
Chapter 3 How to run Edge tests in headless mode in Selenium4
Chapter 4 How to manage driver executables using WebDriverManager
Chapter 5 How to disable infobar warning for Chrome tests in Selenium
Chapter 6 How to maximize and minimize the window in Selenium

WebDriver Commands

Chapter 1 Difference between FindElement and FindElements in WebDriver
Chapter 2 Difference between getText() and getAttribute() method in WebDriver
Chapter 3 WebDriver Browser Commands – get,  getTitle, getCurrentUrl, getPageSource, getClass, close, quit in WebDriver
Chapter 4 WebDriver Navigation Commands – Navigate, Forward, Back, Refresh in  WebDriver
Chapter 5 Selenium Form WebElement Commands – Sendkeys, Clear, Click,Submit
Chapter 6 How to automate selecting Checkbox and Radio Buttons in Selenium WebDriver
Chapter 7 How to Select value from Drop down list or perform Multiple Selection  Operations in WebDriver
Chapter 8 How to get all options in a DropDown list in WebDriver
Chapter 9 How to automate Radio Button in WebDriver
Chapter 10 How to automate BootStrap DropDown using WebDriver
Chapter 15 How to handle Dynamic Web Tables using Selenium WebDriver
Chapter 16 How to get all the values from a Dynamic Table in Selenium WebDriver 
Chapter 17 isDisplayed, isSelected, isEnabled in Selenium
Chapter 18 How to test HTML ordered list in Selenium
Chapter 19 How to test HTML5 validation messages with Selenium

Waits in Selenium

Chapter 1 Implicit and Explicit Wait in Selenium WebDriver
Chapter 2 What is Fluent Wait in Selenium WebDriver

Handle Window and Alerts

Chapter 1 Switch Window Commands in Selenium WebDriver
Chapter 2 How to handle Alerts in Selenium WebDriver
Chapter 3 How to Switch Between Frames in Selenium WebDriver

Selenium Interview Questions and Answers 2026
Advanced Selenium Interview Questions and Answers 2026
Selenium Multiple Choice Questions – MCQ1
Selenium Multiple Choice Questions – MCQ1
Selenium Multiple Choice Questions – MCQ3

Run Cucumber Tests in GitLab CI/CD

Last Updated on

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:

  1. Cucumber 7
  2. TestNG (for Assertions)
  3. Selenium 4
  4. Java 11
  5. Maven/ Gradle
  6. GitLab Account

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:

  • The scripts you want to run.
  • Other configuration files and templates you want to include.
  • Dependencies and caches.
  • The commands you want to run in sequence and those you want to run in parallel.
  • The location to deploy your application to.
  • Whether you want to run the scripts automatically or trigger any of them manually.

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!!

Run Gradle API Tests in GitLab CI/CD

Last Updated On

HOME

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

Prerequisite:

  1. Serenity – 2.6.0
  2. Serenity Cucumber – 2.6.0
  3. Serenity Rest Assured – 2.6.0
  4. Rest Assured – 4.3.2
  5. Java 11
  6. JUnit – 4.13.2
  7. Gradle – 7.2
  8. GitLab Account

Please refer to this tutorial to get the structure and code of the Gradle project with Serenity and Rest API – Serenity BDD with Cucumber and Rest Assured in Gradle

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.

GitLab Section

Step 1 – Create a blank project in GitLab

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

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

To know, how to push the changes to GitLab, please refer to How to push new local GIT Repository to GitLab.

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:

  • The scripts you want to run.
  • Other configuration files and templates you want to include.
  • Dependencies and caches.
  • The commands you want to run in sequence and those you want to run in parallel.
  • The location to deploy your application to.
  • Whether you want to run the scripts automatically or trigger any of them manually.

image : gradle:7.1.0-jdk11 
stages:
  - test

variables:
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

test:
  stage: test
  allow_failure: true
 
# Run the tests
  script:
    - echo "Executing BDD scenarios with Gradle"
    - gradle clean test
    - gradle reports	

 
# Store artifacts
  artifacts:
    when: always
    name: "Gradle Report"
    paths:
    - lib/target/site/serenity/*
    expire_in: 24 h

Image – gradle:7.1.0-jdk11 is used in this test. It is a docker image for Gradle with Java 11 installed in it.

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 and 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 – View GitLab Pipeline

Now, when a new change is committed, a pipeline kicks off and it runs all the tests. To view the pipeline, go to the left panel and click on the Build option. There are a number of sub-options in the Build option, click on the Pipelines.

Step 5 – Run the tests in the GitLab pipeline

The below image shows that the tests are running in the GitLab pipeline.

Step 6 – 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, its 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 “Serenity_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 7 – Download the report

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

Example of Index.html

Example of Serenity Summary Report

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

Run Serenity Tests in GitLab CI/CD

Last Updated on

HOME

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

Table of Contents:

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 like any other browser but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we could not see the browser, but we can see the test results coming on the console. The tests can run in the GitLab pipeline if the tests run in the headless mode.

Prerequisite:

  1. Serenity – 3.2.3
  2. Serenity Cucumber – 3.2.3
  3. JUnit Jupiter – 5.8.0
  4. JUnit Vintage – 5.8.0
  5. Java 11
  6. Maven – 3.8.1
  7. Selenium – 3.141.59
  8. Maven Compiler Plugin – 3.8.1
  9. Maven Surefire Plugin – 3.0.0-M5
  10. Maven FailSafe Plugin – 3.0.0-M5
  11. GitLab Account

Please refer to this tutorial to get the structure and code of the Serenity Project – Integration of Serenity with Cucumber and JUnit5.

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 the 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:

  • The scripts you want to run.
  • Other configuration files and templates you want to include.
  • Dependencies and caches.
  • The commands you want to run in sequence and those you want to run in parallel.
  • The location to deploy your application to.
  • Whether you want to run the scripts automatically or trigger any of them manually.

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 verify
 
# Store artifacts
  artifacts:
    when: always
    name: "Serenity Report"
    paths:
    - target/site/*
    expire_in: 24 h

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

This command lets the pipeline continue running subsequent jobs, even if the previous job is failed.

allow_failure: true

The below command is used to execute the tests from Maven in the docker image.

mvn clean verify

The below command means that the artifact should be generated every time the pipeline is run, irrespective of the fact if the job is successful or failed.

artifacts:
    when: always

The below command provides the name of the artifact. If this is not used, then the artifacts file is named artifacts, which becomes artifacts.zip when downloaded.

artifacts:
    name: "Serenity Report"

The below command provides the path of the files that should be present in the artifact.

artifacts:
    paths:
    - target/site/*

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 and 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, its 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 is 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 “Serenity_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 6 – Download the report

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

Example of Index.html

Example of Serenity Summary Report

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

How to run Chrome tests in headless mode in Selenium4

HOME

This tutorial explains the steps to run the Selenium tests in Chrome browser in headless mode. We are going to run the tests in Selenium 4.

Add the below dependencies to pom.xml or build.gradle.

Add the below dependencies to the project. I have added the Junit dependency because I want to add an assertion and create a test method.

<dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>4.9.1</version>
 </dependency>

 <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-engine</artifactId>
            <version>5.9.2</version>
            <scope>test</scope>
 </dependency>

What is a headless browser?

A headless browser is like any other browser but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we could not see the browser, but we can see the test results coming on the console.

Headless browser testing is generally faster when compared to actual UI testing as it doesn’t wait for the whole page to render before performing any action.

The traditional way is to add –headless, and since version 96, Chrome has a new headless mode that allows users to get the full browser functionality (even run extensions). Between versions 96 to 108 it was  –headless=chrome, after version 109, it is –headless=new.

The complete program looks like as shown below:

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

public class HeadlessChrome_Demo {

    public ChromeDriver driver;

    @Test
    public void test() {

        // Create an object of Chrome Options class
        ChromeOptions options = new ChromeOptions();

        // pass the argument -–headless and maximize to Chrome Options class.
        options.addArguments("--start-maximize");
        options.addArguments("--headless=new");

        // Create an object of Chrome Driver class and pass the Chrome Options object as
        // an argument
        driver = new ChromeDriver(options);

        System.out.println("Executing Chrome Driver in Headless mode..");
        driver.get("https://duckduckgo.com/");

        String titlePage = driver.getTitle();
        System.out.println("Title of Page :" + titlePage);
        Assertions.assertEquals("DuckDuckGo — Privacy, simplified.",titlePage);
        
        // Close the driver
        driver.close();

    }

}

The output of the above program is

Congratulations!! We are able to run Chrome tests in Selenium in headless mode.

Run Robot Framework Tests in GitLab CI/CD

Last Updated On

HOME

This tutorial walks you through the process of running Robot Framework tests in GitLab pipelines. This is a very important step in achieving CI/CD. Ideally, tests should be run after each change (minor/major) before the latest change is merged into the master branch. Let’s assume that 100 changes are merged into the master branch a day and tests are run every time before deployment. In this case, there is no QA manually starting 100 tests a day. Now, what should be done to overcome this problem. Now add a test to your GitLab pipeline. Adding a test stage to your pipeline automatically runs the tests when you run the pipeline. 

Table of Contents

  1. What is GitLab CI/CD Workflow?
  2. What is a headless browser?
  3. Prerequisite
  4. Implementation Steps:
    1. Create a new Project
    2. Create 2 new directories in the new project
    3. Create Test Files
    4. Create Resources file for each page
    5. Execute the tests
  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

What is GitLab CI/CD Workflow?

Once the proposed changes are built, then push the commits to a feature branch in a remote repository that’s hosted in GitLab. The push triggers the CI/CD pipeline for your project. Then, GitLab CI/CD runs automated scripts (sequentially or in parallel) to build as well as to test the application. After a successful run of the test scripts, GitLab CI/CD deploys your changes automatically to any environment (DEV/QA/UAT/PROD). But if the test stage is failed in the pipeline, then the deployment is stopped.

To use GitLab CI/CD, we need to keep 2 things in mind:

a) Make sure a runner is available in GitLab to run the jobs. If there is no runner, install GitLab Runner and register a runner for your instance, project, or group.

b) Create a .gitlab-ci.yml file at the root of the repository. This file is where CI/CD jobs are defined.

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

What is a headless browser?

A headless browser is like any other browser but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we could not see the browser, but we can see the test results coming on the console.

Prerequisite

  1. Install Python
  2. Install PIP
  3. Install Robot Framework
  4. Install Robot framework Selenium Library
  5. Install PyCharm IDE
  6. GitLab Account

Implementation Steps:

Step 1 – Create a new Project

Step 1.1 – Open PyCharm and create a new project. Go to File and select New Project from the main menu.

Step 1.2 – Choose the project location. Click the Browse button next to the Location field and specify the directory for your project.

Deselect the Create a main.py welcome script checkbox because you will create a new Python file for this tutorial.

Click on the Create Button.

Step 1.3 – A new dialog will appear asking to Open the project using any one of the given options. I have selected New Window as I like to have separate windows for each project.

Below is the image of the new project created in PyCharms.

Step 2 – Create 2 new directories in the new project

Right-Click on the project, select New->Directory, and provide the name as TestCases and Resources

Step 3 – Create Test Files

This directory contains multiple test case files consisting of test steps. 

Right-click on the new directory select New File and provide the name LoginPageTests.robot and ForgetPasswordTests.robot as shown below:

Below is the code for LoginPageTests.robot

*** Settings ***
Documentation       Tests to login to Login Page
Library     SeleniumLibrary
Test Setup      Open the Browser with URL
Test Teardown   Close Browser Session
Resource       ../Resources/GenericResources.robot
Resource       ../Resources/LoginResources.robot
Resource      ../Resources/DashboardResources.robot

*** Test Cases ***

Validate Unsuccessful Login using invalid credentials

    LoginResources.Fill the login form     ${valid_username}       ${invalid_password}
    LoginResources.Verify the error message is correct


Validate Unsuccessful Login for blank username

     LoginResources.Fill the login form     ${blank_username}       ${valid_password}
     LoginResources.Verify the error message is displayed for username


Validate Unsuccessful Login for blank password

     LoginResources.Fill the login form     ${valid_username}       ${blank_password}
     LoginResources.Verify the error message is displayed for password


Validate successful Login

    LoginResources.Fill the login form     ${valid_username}       ${valid_password}
    DashboardResources.Verify Dashboard page opens

Below is the code for ForgetPasswordTests.robot

*** Settings ***
Documentation       Tests to validate Forgot Your Password Page functionality
Library     SeleniumLibrary
Test Setup      Open the Browser with URL
Test Teardown   Close Browser Session
Resource       ../Resources/GenericResources.robot
Resource       ../Resources/LoginResources.robot
Resource      ../Resources/ForgetPasswordResources.robot


*** Test Cases ***

Validate Reset Password Functionality

    LoginResources.Go to Forgot Your Password Page
    ForgetPasswordResources.Verify Forgot Your Password Page opens
    ForgetPasswordResources.Fill the Forgot Password Page
    ForgetPasswordResources.Verify the message

Validate Cancel Functionality

    LoginResources.Go to Forgot Your Password Page
    ForgetPasswordResources.Verify Forgot Your Password Page opens
    ForgetPasswordResources.Cancel the Reset Password
    ForgetPasswordResources.Verify that Login Page is displayed

Step 4 – Create a Resource file for each page

It maintains the files which contain page elements as well as corresponding keywords. 

Right-click on the new directory select New File and provide the name as LoginResources.robot, DashboardResources.robot, GenericResources.robot, and ForgetPasswordResources.robot as shown below:

GenericResources.robot contains the keywords that are common to all the tests, like opening of the browser or closing of the browser.

*** Settings ***
Documentation    A resource file with reusable keywords and variables.
Library     SeleniumLibrary

*** Variables ***
${valid_username}     Admin
${valid_password}       admin123
${invalid_username}     1234
${invalid_password}     45678
${blank_username}
${blank_password}
${url}      https://opensource-demo.orangehrmlive.com/web/index.php/auth/login
${browser_name}      Chrome

*** Keywords ***

Open the Browser with URL
    Open Browser   ${url}    headlesschrome
    Maximize Browser Window
    Set Selenium Implicit Wait    5

Close Browser Session
    Close Browser

Below is the code for LoginResources.robot

*** Settings ***
Documentation        All the page objects and keywords of landing page
Library     SeleniumLibrary

*** Variables ***
${login_error_message}      css:.oxd-alert-content--error
${dashboard_title}       css:.oxd-topbar-header-breadcrumb-module
${missing_username_error_message}    xpath://*[@class='oxd-form']/div[1]/div/span
${missing_password_error_message}   xpath://*[@class='oxd-form']/div[2]/div/span
${forgot_password_link}   xpath://div[@class='orangehrm-login-forgot']/p

*** Keywords ***

Fill the login form
    [Arguments]    ${username}      ${password}
   Input Text    css:input[name=username]   ${username}
   Input Password    css:input[name=password]   ${password}
   Click Button    css:.orangehrm-login-button


Verify the error message is correct
    Element Text Should Be    ${login_error_message}    Invalid credentials


Verify the error message is displayed for username
     Element Text Should Be    ${missing_username_error_message}      Required

Verify the error message is displayed for password
      Element Text Should Be    ${missing_password_error_message}      Required

Go to Forgot Your Password Page
    Click Element      ${forgot_password_link}

Below is the code for DashboardResources.robot

*** Settings ***
Documentation        All the page objects and keywords of Dashboard page
Library     SeleniumLibrary

*** Variables ***
${dashboard_title}       css:.oxd-topbar-header-breadcrumb-module

*** Keywords ***

Verify Dashboard page opens
    Element Text Should Be    ${dashboard_title}      Dashboard

Below is the code for ForgetPasswordResources.robot

*** Settings ***
Documentation       All the page objects and keywords of Forget Password page
Library     SeleniumLibrary

*** Variables ***
${forgot_page_title}       css:.orangehrm-forgot-password-title
${username}     css:.oxd-input--active
${reset_btn}     css:.orangehrm-forgot-password-button--reset
${cancel_btn}    css:.orangehrm-forgot-password-button--cancel
${reset_message}      xpath://div[@class='orangehrm-card-container']/h6
${login_page_title}   xpath://*[@class='orangehrm-login-slot']/h5

*** Keywords ***

Verify Forgot Your Password Page opens
    Element Text Should Be    ${forgot_page_title}      Reset Password

Fill the Forgot Password Page
   Input Text        ${username}     abc@gmail.com
   Click Button    ${reset_btn}

Verify the message
    Element Text Should Be    ${reset_message}      Reset Password link sent successfully

Cancel the Reset Password
    Click Button    ${cancel_btn}

Verify that Login Page is displayed
    Element Text Should Be    ${login_page_title}       Login

All the below-mentioned keywords are derived from SeleniumLibrary. The functionality of keywords mentioned above:

1. Create Webdriver − The keyword creates an instance of Selenium WebDriver.

2. Go To – This keyword navigates the current browser window to the provided url.

3. Maximize Browser Window – This keyword maximizes the current browser window.

4. Set Selenium Implicit Wait – This keyword sets the implicit wait value used by Selenium.

5. Input Text − This keyword is used to type the given text in the specified textbox identified by the locator name:username.

6. Input Password – This keyword is used to type the given text in the specified password identified by the locator name:password.

The difference compared to Input Text is that this keyword does not log the given password on the INFO level.

7. Click button – This keyword is used to click the button identified by the locator. In this case, it is “Login” button.

8. Element Text Should Be – This keyword is used to verify that the current page contains the exact text identified by the locator. Here, we are checking the exact text “Invalid Credentials”.

These keywords are present in SeleniumLibrary. To know more about these keywords, please refer to this document – https://robotframework.org/SeleniumLibrary/SeleniumLibrary.htm.

To run this script, go to the command line and go to directory tests.

Step 5 – Execute the tests

We need the below command to run the Robot Framework script.

robot .

The output of the above program is

GitLab Section

Step 6 – Create a blank project in GitLab

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

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

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

Step 8 – 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:

  • The scripts you want to run.
  • Other configuration files and templates you want to include.
  • Dependencies and caches.
  • The commands you want to run in sequence and those you want to run in parallel.
  • The location to deploy your application to.
  • Whether you want to run the scripts automatically or trigger any of them manually.

Below is the sample pipeline.

stages:
  - test

image: ppandiyan/robotframework

run-tests:
  stage: test
  script:
    - robot --outputdir testOutput .
  artifacts:
    paths:
      - testOutput
    expire_in: 1 day

Image – ppandiyan/robotframework is used in this test. This docker file contains headlesschrome, headlessfirefox and Python2.7.

This gitlab-ci.yml has only 1 stage – a test that contains the command to run the tests as well as also create an artifact that contains all the surefire reports which can be saved as Test Evidence.

Step 9 – 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 10 – 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.

Let us see the logs of the execution it shows that all the tests are passed here.

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 “testOutput” and the folder contains reports, logs as well as output files. This artifact gives us the option to download the reports or browse the report. This report will be available for 1 day only as mentioned in the gitlab-ci.yml.

Step 11 – Download the report

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

Example of Report.html

Example of Log.html

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

Run Selenium Tests in GitLab CI/CD

Last Updated on

HOME

This tutorial explains the process to run the Selenium Tests in the GitLab pipeline. This is a very important step towards achieving CI/CD. Ideally, the tests need to run after any change (minor/major) before merging the latest change to the master branch. Suppose there are 100 changes merged to the master branch in a day. It is expected to run the tests every time before deployment. In this case, any QA won’t want to start the tests manually 100 times in a day. Now, what should be done to overcome this problem. Now, adding tests to the GitLab pipeline comes into the picture. We can add a test stage to the pipeline and the tests will run automatically when the pipeline run.

Table of Contents

  1. Prerequisite
  2. What is GitLab CI/CD Workflow?
  3. What is a headless browser?
  4. Implementation Steps
    1. Create a new Maven Project
    2. Add the dependencies to the POM.xml
    3. Create the Test Code
    4. Create testng.xml to run the tests
    5. Run the tests through command line
  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

  1. Selenium
  2. TestNG/JUnit (for Assertions)
  3. Java 11
  4. Maven/ Gradle
  5. GitLab Account

What is GitLab CI/CD Workflow?

Build the proposed changes. Then, push the commits to a feature branch. This branch should be in a remote repository that’s hosted in GitLab. The push triggers the CI/CD pipeline for your project. Then, GitLab CI/CD runs automated scripts (sequentially or in parallel) to build as well as to test the application. After a successful run of the test scripts, GitLab CI/CD deploys your changes automatically to any environment (DEV/QA/UAT/PROD). But if the test stage is failed in the pipeline, then the deployment is stopped.

After the implementation works as expected:

  • Get the code reviewed and approved.
  • Merge the feature branch into the default branch.
    • GitLab CI/CD deploys your changes automatically to a production environment.

To use GitLab CI/CD, we need to keep 2 things in mind:

a) Make sure a runner is available in GitLab to run the jobs. If there is no runner, install GitLab Runner and register a runner for your instance, project, or group.

b) Create a .gitlab-ci.yml file at the root of the repository. This file is where CI/CD jobs are defined.

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

What is a headless browser?

A headless browser is like any other browser, but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we cannot see the browser. However, we can see the test results coming on the console.

To explain, I have created 2 Selenium tests and used TestNG for asserting the tests. The tests will run on a headless Chrome browser. One more thing to keep in mind is that when tests run on a headless Chrome browser, the window screen won’t be full screen. So, the screen needs to be maximized explicitly otherwise some of the tests would fail.

Implementation Steps

Step 1 – Create a new Maven Project

Step 2- Add the dependencies to the POM.xml

Add the below-mentioned dependencies that need to add to the project to the pom.xml in Maven Project.

 <dependencies>

        <dependency>
            <groupId>io.github.bonigarcia</groupId>
            <artifactId>webdrivermanager</artifactId>
            <version>5.1.0</version>
        </dependency>

        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>3.141.59</version>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.5</version>
            <scope>test</scope>
        </dependency>
                   
    </dependencies>
    <build>
     <plugins>
     
     <!--  Compiler Plugin -->
    
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
           <source>11</source>
           <target>11</target>
        </configuration>
    </plugin>
     
      <!--  Plugin used to execute tests -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M5</version>
        <configuration>
          <suiteXmlFiles>
            <suiteXmlFile>testng.xml</suiteXmlFile>
          </suiteXmlFiles>
        </configuration>
      </plugin>
     </plugins>
  </build>
</project>

As explained in one of the previous tutorial, it is needed to add the maven-surefire-plugin to run the TestNG tests through the command line.

Step 3 – Create the Test Code

This is the BaseTest Class. The WebDriver is initialized here. It operates in headless mode and full screen. At the end, the WebDriver is closed.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;

import io.github.bonigarcia.wdm.WebDriverManager;

public class BaseTest {
	
	WebDriver driver;
	
	@BeforeMethod
	public void beforeTests() {
        WebDriverManager.chromedriver().setup();
        ChromeOptions options=new ChromeOptions();
        options.setHeadless(true);
        options.addArguments("window-size=1920,1200");
        driver=new ChromeDriver(options);
        driver.get("https://opensource-demo.orangehrmlive.com/");
    }

	@AfterMethod
    public void afterTests() {
        driver.quit();
    }

}

There are 2 different pages that need to be tested – LoginPage and ForgetPasswordPage

LoginPage contains the tests to log in to the application. After successful login, the application moves to the next webpage – HomePage. You can see that BaseTest class is extended in both the Test classes.

import org.openqa.selenium.By;
import org.testng.Assert;
import org.testng.annotations.Test;

@Test
public class LoginPage extends BaseTest{
	
	@Test
	public void validCredentials() throws InterruptedException {

	        driver.findElement(By.name("txtUsername")).sendKeys("Admin");	        
	        driver.findElement(By.name("txtPassword")).sendKeys("admin123");
	        driver.findElement(By.id("btnLogin")).click();
	         String newPageText = driver.findElement(By.xpath("//*[@id='content']/div/div[1]/h1")).getText();
	        System.out.println("newPageText :" + newPageText);
	        Assert.assertEquals(newPageText,"Dashboard");

	}

}

ForgetPasswordPage

import org.openqa.selenium.By;
import org.testng.Assert;
import org.testng.annotations.Test;

@Test
public class ForgetPasswordPage extends BaseTest{
	
	@Test
	public void getHeading() {
		
		Thread.sleep(1000);
		driver.findElement(By.xpath("//*[@id='forgotPasswordLink']/a")).click();
		String heading = driver.findElement(By.xpath("//*[@id='content']/div[1]/div[2]/h1")).getText();
		System.out.println("Title : "+ heading );
		Assert.assertEquals(heading, "Forgot Your Password?");
	}
	
}

Step 4 – Create testng.xml to run the tests

Now, let’s create a testng.xml to run the TestNG tests. If JUnit is used instead of TestNG, then this step is not needed.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="Suite">
  <test name="Test">
    <classes>
      <class name="org.example.DockerDemo.LoginPage"/>
      <class name="org.example.DockerDemo.ForgetPasswordPage"/>
    </classes>
  </test> <!-- Test -->
</suite> <!-- Suite -->

Step 5 – Run the tests through command line

Now, let us execute the tests through the command line. Go to the place where the pom.xml of the project is placed and use the below command to run the tests. This step makes sure that all the tests are running as expected.

mvn compile test

GitLab Section

Step 6 – Create a blank project in GitLab

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

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

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

Step 8 – 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:

  • The scripts you want to run.
  • Other configuration files and templates you want to include.
  • Dependencies and caches.
  • The commands you want to run in sequence and those you want to run in parallel.
  • The location to deploy your application to.
  • Whether you want to run the scripts automatically or trigger any of them manually.
image: markhobson/maven-chrome

stages:
  - test

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

test:
  stage: test
  allow_failure: true

# Run the tests  
  script:
    - mvn $MAVEN_OPTS clean package
    - mvn compile test

# Store artifacts
  artifacts:
    when: always
    name: "report"
    paths:
    - target/surefire-reports/*
    expire_in: 1 h

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

This gitlab-ci.yml has only 1 stage. It is a test stage that contains the command to run the tests. It also creates an artifact that contains all the surefire reports. These reports can be saved as Test Evidence.

Step 9 – 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 10 – 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 failed here which means that the execution is completed. Let us see the logs of the execution it shows that out of 2 tests, 1 test passed and 1 test failed. This shows that tests are running successfully 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 “report” and the reports in this folder come from the path /target/surefire-reports. This artifact gives us the option to download the reports or browse the report. This report will be available for 1 hour only as mentioned in the gitlab-ci.yml.

Step 11 – Download the report

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

Example of Emailable-Report.html

Example of Index.html

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