Headless browser testing using Selenium Webdriver

Photo by Edu Lauton on Unsplash

The benefits of Automation testing for the purpose of regression are well known. It has made the jobs of QA Engineers easier by simply typing a command to run automation suite to ensure nothing breaks in Production environment after a new release.

One drawback of running UI automation from your machine is that it “hijacks” your machine making it extremely difficult, if not impossible, to perform any other tasks while your automation code is running. If you are running your automation via a cron job in the wee hours of night, then you don’t face the issue. However, in today’s increasingly responsive business environment, Live releases are being made frequently and mostly during normal business hours. Headless browser testing is a great way to tackle this issue. It enables the automation code to run in the background allowing the QA engineer to continue with his/her tasks from the same computer.

Below is a list of what I see as key advantages and disadvantages of Headless browser testing.


  1. You can run your automation suite at any time of the day without the browser taking over your monitor screen.
  2. This allows you to continue your work while the automation code is running.
  3. Less chances of failure due to ‘human intervention.’
  4. Any desired screenshots are still stored just like in regular automation testing.
  5. Headless browser testing is supposed to run faster than actual UI testing, because the browser doesn’t need to wait for the entire page to finish rendering before performing an action.


  1. When you run headless tests, you are not really mimicking the real user experience.
  2. Cosmetic bugs can’t be identified while doing headless browser testing, such as the location of a button, or the color of a web element, etc.

Until recently, modern browsers like Chrome and Firefox did not offer any built-in support for running their browsers in Headless mode. QA engineers would use open source headless browsers such as PhantomJS or Zombie JS to achieve this purpose. However much awaited headless mode is made available now for Chrome 59 and Firefox 56 versions.

Below I will show how easy it is to switch your UI automation code to the Headless mode. Since selenium with Java is the most widely used automation tool, I will talk about using Headless browser testing using Selenium webdriver.

In order to make your code configurable to use different browsers and switch between headless and UI testing modes, let’s create a Properties file. For this example we will name the properties file as global.properties.

global.properties file.

#Acceptable values are ‘chrome’ or ‘firefox’.

Now simply load the values of the Properties file in your code. In order for running Chrome or Firefox in headless mode, you would have to import ChromeOptions and FirefoxOptions for your Java class. Also to toggle between UI testing or headless testing, create a boolean. (In the example below, we are using a boolean named as headless).

Below code shows the implementation.

Since our properties file has browser set as ‘chrome’ and headless set as ‘true’ , the code will run as Headless Chrome. You can easily switch to UI mode by changing the value of property headless in global.properties file.

Running headless browser testing with older browser versions

In order to run Headless automation with older browser versions, you can use other headless browsers such as PhantomJS. Simply download the PhantomJS executable from their website. We will now add a few lines of code to the code snippet above to allow the user to run headless browser testing using PhantomJS.

YourClass after adding code for PhantomJS Headless browser

Note: Newer versions of selenium-server-standalone-v.v.v.jar don’t bundle the jar for PhantomJSDriver dependency.

To resolve this issue, download the jar phantomjsdriver-1.1.0.jar and add it as an external jar to your project.

Our global.properties file will now look like this:

#Acceptable values are ‘chrome’, ‘firefox’ or ‘phantom’.

Can we still take screenshots while running the code in headless browser mode?

The great news is that you don’t have to make any changes in your existing code in order to take screenshots. Below is sample code for taking screenshots during automation. The code employs libraries from Junit and cucumber to enable your code to take a screenshot of the screen where your automation code encountered a failure.

Calling the function below in your automation code will allow you to take a screenshot of the web page at that particular instance. This screenshot will be then saved into a folder named ‘screenshots’.

Capturing screenshots on demand!


I hope you found the provided information useful, and it will add more value to your existing test automation codebase. Please provide feedback in the Comments section below. This will help me to write better in the future. Also, feel free to connect with me at linkedIn and github.

Thanks for your time.