Test Automation - Initializing Selenium WebDriver - The Complete Guide

Introduction

In this article, I will review different ways in Java to initialize the WebDriver object,

This object drives the browser automation. For every initialization way, I will display its advantages and disadvantages. The implementation is performed with ChromeDriver, which is a program that is used as a wrapper that controls the Chrome browser that is running our test suite. Our driver object is sending its commands to the ChromeDriver and ChromeDriver is manipulating the Chrome browser.

Method 1 - Initialize the object with an absolute redirect to the path to the driver object

First, we need to download the ChromeDriver executable to our computer; the download page is: https://chromedriver.chromium.org/downloads

You must select a version that is compatible with your browser version.

Specify the path by setting a system variable named webdriver.chrome.driver

The implementation is:

@Test
public void test() {
    System.setProperty("webdriver.chrome.driver", "/absolute/path/to/binary/chromedriver");
    WebDriver driver = new ChromeDriver();
}

Disadvantages

• Because of the absolute reference, when our automation project is written by a number of developers within a repository stored in Git, if they do not have the unique path that exists on our computer, the redirect will fail and the browser will not restart.

• Because there are different executables for different operating systems - our program will not run on different operating systems we did not attach the executable file, for example, when we work on Windows, then on Linux, our tests will not run.

• There is no standardization on which version of Chrome browser the consumer of our test framework will use, for example, I use Chrome 74, and another automation developer might use Chrome 76 user that requires a different ChromeDriver version.

Method 2 - Initialize the object with a relative reference to an executable file in our automation project

There is a system variable called “user.dir” using System built-in getProperty method that receives a string as a variable that is the library in which our user is working (according to Java documentation on system variables).

In this way, we need to attach the ChromeDriver to our project and then refer to its relative location.

The implementation is:

@Test
public void test() {
    System.setProperty("webdriver.chrome.driver", System.getProperty("user.dir") + "/relative/path/to/binary/chromedriver");
    WebDriver driver = new ChromeDriver();
}

Disadvantages

• Because there are different executable different operating systems - our program will not run on the other operating system from the executable file that we have included in our project.

• We can write a logic that checks the operating system in which we are running and accordingly decide which driver to initialize, but this logic will increase the running time of our testing suite.

• We are required to manually update the ChromeDriver version from time to time, according to our Selenium version, also upgrades to the Chrome browser itself may require version upgrades.

Advantages

• Because the reference is relative, the program can be included as part of our automation project.

Method 3 – Embed the driver as an environment variable

For Windows users, I recommend installing with Chocolatey, which is Package Manager, Apart from installing ChromeDriver, it also makes it an environmental variable. After a successful installation typing “chromedriver” on the command line, and we will see it starting to run.

C:\Users\nir.tal>chromedriver
Starting ChromeDriver 2.46.628402 (536cd7adbad73a3783fdc2cab92ab2ba7ec361e1) on port 9515
Only local connections are allowed.
Please protect ports used by ChromeDriver and related test frameworks to prevent access by malicious code.

The implementation is:

@Test
public void test() {
    WebDriver driver = new ChromeDriver();
}

Disadvantages

• The method is suitable for local development and not for CI/CD. Any agent required to join the testing effort will have to install its own browsers and drivers.

• We may face compatibility issues when our tests will be running tests on different browsers / OS / and driver versions.

Advantages

• No need to hard code the ChromeDriver path.

• The installation is agnostic to the operating system – the package manager knows which driver is needed to be installed.

Method 4 – WebDriverManager

From GitHub:

WebDriverManager allows automating the management of the binary drivers (e.g.chromedriver,geckodriver, etc.) required by Selenium WebDriver.

The usage of WebDriverManager allows us to skip the installation of ChromeDriver. The process of deciding which chrome driver to use is controlled by us using WebDriverManager configuration.

We could use the latest ChromeDriver version:

@Test
public void test() {
    WebDriverManager.chromedriver().setup();
    WebDriver driver = new ChromeDriver();
}

Or we could select a specific version we want to use in the following example we want to use ChromeDriver version 2.46:

@Test
public void test() {
    WebDriverManager.chromedriver().version("2.46").setup();
    WebDriver driver = new ChromeDriver();
}

Disadvantages

• The only disadvantage using this method is we need to have the Chrome browser manually installed in order for the magic to happen.

Advantages

• As mentioned before - no need to manually install the driver locally anymore, WebDriverManager does it for us.

Method 5 – Selenium Grid

Using the Selenium Grid, we have a centralized system that controls all the drivers/browsers we want to use in the tests.

The implementation is:

@Test
public void test() {
    DesiredCapabilities capabilities = DesiredCapabilities.chrome();
    driver = new RemoteWebDriver(new URL("http://ip_of_the_machine_where_hub_running:port/wd/hub"), capabilities);
}

Disadvantages

• Knowledge of installation and configuration of the Grid environment is required.

Advantages

• Working with a central server that coordinates the work with the browsers and drivers we consume for testing.

• Compatibility - ChromeDriver versions will be compatible with Chrome browser versions, and we will not encounter any compatibility issues between the ChromeDriver version and the browser version.

• Scalability – we can increase the number of nodes according to our workload.

In conclusion

In this article, we reviewed different ways to initialize the ChromeDriver object. My recommendation is to combine a local installation of ChromeDriver for running tests locally and Debugging, in conjunction with Selenium Grid.

In our advanced automation course, we will learn how to deploy a Grid infrastructure on containers using Docker in a few simple steps that will also give us video abilities.

Happy testing!