Selenium Grids Components and its Architecture

Profile picture for user devraj

Selenium Grid has a Hub and Node Architecture.

Selenium Grid Architecture

 

CI/CD Server: Jenkins and Server

Client: Client Libraries in different languages.

Hub: Hub is a central point where all your tests are sent. Each Selenium Grid consists of exactly one hub. The hub needs to be reachable from the respective clients (i.e. CI server, Developer machine etc.) The hub will connect one or more nodes that tests will be delegated to.

  • Intermediary and manager
  • Accepts requests to run tests
  • Takes instructions from client and executes them remotely on the nodes
  • Manages threads
  • The hub is the central point where you load your tests into.
  • There should only be one hub in a grid.
  • The hub is launched only on a single machine.

Node: Nodes are different Selenium instances that will execute tests on individual computer systems. There can be many nodes in a grid. The machines which are nodes do not need to be the same platform or have the same browser selection as that of the hub or the other nodes. A node on Windows might have the capability of offering Internet Explorer as a browser option, whereas this wouldn’t be possible on Linux or Mac.

  • Where the browsers live
  • Registers itself to the hub and communicates its capabilities
  • Receives requests from the hub and executes them
  • Nodes are the Selenium instances that will execute the tests that you loaded on the hub.
  • There can be one or more nodes in a grid.
  • Nodes can be launched on multiple machines with different platforms and browsers.

JSON  wire protocol: 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. 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 RemoteWebDriverserver 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.

How it 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).

Our code (Ruby, Java, c# ) communicates with Selenium WebDriver or otherwise the Browser specific client driver that acts as HTTP proxy. Ex: chromedriver.exe, IEDriverServer.exe, SafariDriver etc.

A session is created and then the HTTP request and response communication happens. Request is asking to click, set text etc. Response is getting the result of each command, get text, results of execution and so on

The difference between Selenium RC [Selenium 1.0 and earlier] and WebDriver is that WebDriver makes native browser calls whereas RC injects javascript into the browser that in turn gets executed.