Let's try to understand why we need Selenium Grid by analyzing a scenario. You have a web application that needs to be tested on the following browser-machine combinations:

• Google Chrome on Windows 10
• Google Chrome on macOS
• Internet Explorer 11 on Windows 10
• Firefox on Linux

We can simply alter the test script we created in the previous chapter and point to the Selenium Standalone Server running on each of these combinations (that is, Windows 10, macOS, or Linux), as shown in the following code.

Windows 10: 

DesiredCapabilities caps = new DesiredCapabilities();
caps.setBrowserName("chrome");
caps.setPlatform(Platform.WIN10);
WebDriver driver = new RemoteWebDriver(new URL("http://<win_10_ip>:4444/wd/hub"), capabilities);

macOS: 

DesiredCapabilities caps = new DesiredCapabilities();
caps.setBrowserName("chrome");
caps.setPlatform(Platform.MAC);
WebDriver driver = new RemoteWebDriver(new URL("http://<mac_os_ip>:4444/wd/hub"), capabilities);

Linux: 

DesiredCapabilities caps = new DesiredCapabilities();
caps.setBrowserName("chrome");
caps.setPlatform(Platform.LINUX);
WebDriver driver = new RemoteWebDriver(new URL("http://<linux_ip>:4444/wd/hub"), capabilities);

In the preceding code, your test scripts are tightly coupled to the machines that host the target platform and the target browsers. If the Windows 10 host changes, you should refactor your test script to handle that. This is not an ideal way to design your tests. The focus of your test scripts should be on the functionality of your web application and not on the infrastructure that is used to execute these test scripts. There should be a central point to manage all the different environments. To solve this, we make use of Selenium Grid.

The Selenium Grid offers a cross-browser testing environment with several different platforms (such as Windows, Mac, and Linux) to execute tests. The Selenium Grid is managed from a central point, called the hub. The hub has the information of all the different testing platforms, known as nodes (the machines that have the desired operating systems and browser versions and connected to the hub). The hub assigns these nodes to execute tests whenever the test scripts request them, based on the capabilities requested by the test. The following diagram shows what a Selenium Grid looks like:

In the preceding diagram, there is one hub, four nodes of different platforms, and the machine where the test scripts are located. The test script will communicate with the hub and request a target platform to be executed. The hub assigns a node with the target platform to the test script. The node executes the test script and sends the result back to the hub, which in turn forwards the results to the test script. This is what Selenium Grid looks like and how it works at a high level.

Now that we have seen how Selenium Grid works theoretically, let's see what works as hubs and nodes in it. Fortunately, as we are dealing with Selenium Grid, we can use the same Remote WebDriver server that we used in the previous chapter to work as Selenium Grid as well. If you remember, we used seleniumserver-standalone-3.12.0.jar to start as a Selenium Standalone Server. We can use the same JAR file to be started in the hub mode on the hub machine, and a copy of the JAR file can be started in the node mode on the node machine. Try executing the following command on your JAR file:

java –jar selenium-server-standalone-3.12.0.jar –help

The following output shows how to use the server in a grid environment:

You will see two options: to use it as a Standalone Server, which acts as a Remote WebDriver, and to use it in a grid environment, which describes Selenium Grid. In this chapter, we will use this JAR file as a Selenium Grid.