{{announcement.body}}
{{announcement.title}}

Selenium Grid Tutorial: Setup and Cross-Browser Testing

DZone 's Guide to

Selenium Grid Tutorial: Setup and Cross-Browser Testing

Learn about the Selenium Grid testing tool, how it works, and how to take advantage of it for performance testing.

· Performance Zone ·
Free Resource

What Is Selenium Grid?

Selenium Grid is a testing tool which allows us to run our tests on different machines against different browsers. It is a part of the Selenium Suite which specializes in running multiple tests across different browsers, operating systems, and machines. You can connect to it with Selenium Remote by specifying the browser, browser version, and operating system you want through Selenium Remote’s Capabilities.

There are two main elements to Selenium Grid — a hub and nodes.

What Is a Hub?

In Selenium Grid, the hub is a computer which is the central point where we can load our tests. The hub also acts as a server, so it acts as a central point to control the network of test machines. The Selenium Grid has only one hub and it is the master of the network. When a test with given DesiredCapabilities is given to hub, it searches for the node which matches the given configuration. For example, you can say that you want to run the test on Windows 10 and Chrome browser with any version. The hub will try to find a machine in the Grid which matches the criterion and will run the test on that machine. If there is no match, the hub returns an error. There should be only one hub in a Grid.

What Is a Node?

In Selenium Grid, a node is a test machine which opts to connect with the hub. This test machine will be used by the hub to run tests on. A Grid network can have multiple nodes. A node is supposed to have different platforms, i.e. different operating system and browsers. The node does not need the same platform for running as that of the hub.

How Selenium Grid Works

First, you need to create a hub. Then you can connect (or “register”) nodes to that hub. Nodes are where your tests will run, and the hub is responsible for making sure your tests end up on the right one (e.g., the machine with the operating system and browser you specified in your test).

Architecture and RemoteWebDriver Workflow

You can use RemoteWebDriver the same way you would use WebDriver locally. The primary difference is that RemoteWebDriver needs to be configured so that it can run your tests on a separate machine. The RemoteWebDriver is composed of two pieces: a client and a server. The client is your WebDriver test and the server is simply a Java servlet, which can be hosted in any modern JEE app server.

RemoteWebDriver is an implementation class of the WebDriver interface that a test script developer can use to execute their test scripts via the RemoteWebDriver server on a remote machine.

There are two parts to RemoteWebDriver: a server (hub) and a client (node).

The RemoteWebDriver server is a component that listens on a port for various requests from a RemoteWebDriver Once it receives the requests, it forwards them to any of the following: Firefox Driver, IE Driver, or Chrome Driver, whichever is asked.

The language-binding client libraries that serve as a RemoteWebDriver The client, as it used to when executing tests locally, translates your test script requests to JSON payload and sends them across to the RemoteWebDriverserver using the JSON wire protocol.

When you execute your tests locally, the WebDriver client libraries talk to your Firefox Driver, IE Driver, or Chrome Driver directly. Now, when you try to execute your tests remotely, the WebDriver client libraries talk to the RemoteWebDriverserver and the server talks to either the Firefox Driver, IE Driver, or Chrome Driver, whichever the WebDriver client asks for.

Image title

We will do this step by step as we move in this tutorial, but first let’s look at the overall architecture diagram as to how the workflow happens. Some jargon below.

JSON over wire: JSON messages hold the entire information that is required by the server [can be Selenium GRID or WebDriver components] and hence instead of RPC, plain JSON messages are exchanged between server and client. Also referred to as WebDriver protocol.

Desired Capabilities: Object in automation code that has requesting browser configuration information.

RemoteWebDriver: Object in automation code that knows how to communicate remotely with WebDriver / Selenium GRID.

Starting a Hub

We are now going to launch a hub. Open the command prompt and navigate to the C: Drive, because that is the directory where we placed the Selenium Server. On the command prompt, type:

 java -jar selenium-server-standalone-3.3.1.jar -role hub 

Image title

To verify whether the hub is running, open the browser and navigate to http://localhost:4444.

Image title

Now click the Console link and then click View Config. The config of the hub should be displayed like this:

Image title

Click on View Config.

Set Up the Node Machine

Ideally, the Node Machine has to be different from the Hub Machine, but to maintain the simplicity of this tutorial, I am setting up the Node on the same machine where I have the Hub running. The steps are the same, except that the IP address is changed to the Node Machine IP Address.

To register the Hub Machine with Node Machine, type:

java -jar selenium-server-standalone-3.3.1.jar -role node -hubhttp://192.168.1.164:4444/grid/register -port 5555


Image title

After executing the command, return to the Hub and navigate the URL http://localhost:4444 or http://192.168.1.164:4444 and the hub will now display the node which is attached to it.

Image title


Topics:
performance, selenium grid, testing, tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}