Selenium Grid Tutorial: Parallel Testing Guide with Examples

Faisal Khatri

Posted On: July 8, 2024

view count338463 Views

Read time17 Min Read

Selenium Grid, an essential component of the Selenium suite, enables you to run test cases simultaneously in different browsers and browser versions. Running tests sequentially on a single machine is always time-consuming, as you can only load a few browsers on your local machine, limiting testing capabilities (e.g., Windows couldn’t test Safari).

This is where the Selenium Grid setup allows testing on all major browsers, operating systems, and mobile devices, ensuring broad browser coverage and a uniform user experience.

What is a Selenium Grid?

Selenium Grid helps in running the Selenium tests on remote machines. It makes use of a proxy server that is run using a Selenium server and allows for the maintenance of different browser configurations at the central level. It enables the tests to run in parallel on other browser versions, thus helping perform cross browser testing.

Moreover, Selenium Grid allows parallel testing against various browsers and OS combinations through a client-server model. Here, the server is known as the Hub, which has multiple clients with which to interact.

Why Use Selenium Grid?

Selenium Grid eases the various tasks while performing automated testing. Here is why you should use Selenium Grid setup to run your test suites:

  • Open Source and Free: Selenium Grid is an open-source project. Teams can use it for free. The documentation is updated regularly with every release, making things like installation, configuration, and usage easier for the users.
  • Enables Cross Browser Testing: Multiple browsers are gaining popularity, and every person prefers to use the browser of his choice for browning websites. It becomes necessary for businesses to test their websites on multiple browsers. Selenium Grid 4 enables the software teams to perform cross browser testing quickly, allowing them to configure multiple browsers easily.
  • Supports Multiple Browser Versions: Another important feature is that Selenium Grid allows users to configure multiple browser versions easily. This helps test websites in different browsers and their versions, enabling teams to detect the issues and fix them at the earliest.
  • Supports Parallel Testing: This is one of the most important features behind using Selenium Grid for testing. It helps run the tests in parallel, allowing the teams to save time on test execution and get faster results and feedback on the builds.

Features of Selenium Grid

The following are the salient features of Selenium Grid 4:

  • Architecture Support: In the earlier version of Selenium Grid, only two processes were available, i.e., Hub and Nodes. The Selenium Grid 4 architecture supports the following six processes, which allows for deployment in different ways:
    • Router
    • Distributor
    • Session Map
    • New Session Queue
    • Node
    • Event Bus
  • Different Grid Roles: Selenium Grid can be configured in the following three ways:
    • Standalone Mode
    • Classical Grid (Hub and Node)
    • Fully Distributed (Event Bus, New Session Queue, Session Map, Distributor, Router and Node)
  • Docker Support: Selenium Grid offers out-of-the-box support for Docker. The Docker daemon runs on port 2375.
  • Observability: Observability in Selenium Grid allows understanding and debugging of internal working as it is designed to be fully distributed. The following three are the main pillars that help in providing detailed insights into observability.
    • Traces
    • Metrics
    • Logs
  • GraphQL Query Support: GraphQL, a query language for APIs, can be used to query and fetch the data that the user requires. With Selenium Grid, GraphQL queries are supported. A simple query can fetch the details of the session, node and grid, current session count, max session count, all session details, etc.
  • Support for Customizing a Node: With Selenium Grid, the Nodes can be customized and updated according to the prerequisite for test execution. For example, doing some additional setup before the session begins execution, similarly running clean-up jobs post-session is complete.
  • Support for External Data Store: Selenium Grid allows us to save the information related to the currently running sessions into an external data store that could be backed by our favorite database, or the Redis Cache system can also be used.

Note: With Selenium 4 in place, Selenium Grid 3 has been deprecated, and the official Selenium documentation recommends using the Selenium Grid 4. To learn about the changes between Selenium Grid 3 and Selenium 4, refer to Selenium 3 vs Selenium 4.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest video tutorials on Selenium testing.

Components of Selenium Grid

The following are the six main components of Selenium Grid:

components-of-selenium-grid

Source

  • Router: Acts as the gateway for the grid, receiving external requests and directing them to the right component for handling.
  • Distributor: Manages the registration and capabilities of Nodes in the grid. It also assigns new session requests to the appropriate Nodes from the Session Queue and updates the Grid’s model with Node status.
  • Session Map: Stores the links between Session IDs and Nodes, facilitating efficient request routing by the Router.
  • Session Queue: Holds incoming session requests in a First In, First Out (FIFO) order. It includes settings for request timeouts and retry intervals, ensuring organized and efficient processing of requests.
  • Node: Executes tests within a distributed network. To receive appropriate test requests, Nodes with specific configurations must register with the Distributor.
  • Event Bus: Facilitates internal communication between grid components using messages to avoid direct HTTP calls. It is activated when the grid starts in fully distributed mode.

How to Configure a Selenium Grid Setup?

For Selenium Grid setup, here are some prerequisites that you need to follow:

  1. Ensure system installation of Java Runtime Environment (JRE) or Java Development Kit (JDK). Prefer the latest JDK version; however, any version above Java 11 suffices (Java 11 is the minimum version supported by Selenium).
  2. Download Selenium Standalone server JAR files.
  3. Download the Java JAR files.

Now, let’s see the steps for Selenium Grid setup implementation:

Step 1: Configure a Standalone Grid

Standalone Grid provides a fully functional grid with a single command within a single process. It perfectly combines all the grid components and can run on a single machine.

The following command can be run from the terminal to start the Selenium Grid in Standalone Mode:

Ensure you navigate to the folder where you downloaded and extracted the Selenium JAR files. These files are located on My Computer in the H:\selenium_grid\ folder.

After executing the command, navigate to http://localhost:4444 to check the fully functional Selenium Grid.

fully-functional-selenium-grid-with-four-instances-of-chrome-firefox-edge-and-ie-browsers

It can be seen that Selenium Grid is fully functional with four instances of Chrome, Firefox, Edge, and IE browsers.

Step 2: Configure Hub and Nodes

To start the Hub, open a command prompt or terminal, navigate to the directory where the Selenium Standalone Server JAR file is saved, and run the below command:

This command would launch a Selenium Grid hub on port 4444 by default. It can be verified by navigating to http://localhost:4444

command-to-start-selenium-grid-hub-using-selenium-standalone-server-jar-file

Next, we need to configure the Nodes to make it fully functional.

After the Hub is started, the Nodes need to be set up to run the browser session for test execution. The Nodes can be set up in different machines. However, it should be noted that these machines should have a JDK/JRE already installed. The Nodes can also be set up on the same machine Hub runs.

To configure a Node, open a command prompt or terminal and navigate to the directory where you saved the browser driver files.

Step 3: Configure Chrome Browser in the Selenium Grid Setup

The following command should be executed in the new instance of the command prompt to start a Node with the Chrome browser:

The above command will start a Node with Chrome browser with one session on port 6161. If we need to increase the session, we can update the value for the max-sessions parameter in the above command.

The Node can be verified on the Selenium Grid UI by navigating to http://localhost:4444.

configure-chrome-browser-in-the-selenium-grid-setup-with-the-command-to-start-a-node-with-chrome-browser-on-port-6161

Let’s now add another node with the Firefox browser to the grid.

Step 4: Configure Firefox Browser in the Selenium Grid Setup

Open a new instance of the command prompt or terminal and run the following command:

The above command will spin a new Node with the two Firefox browser sessions running. Note that we have started this Node on a different port,i.e., 6162.

command-prompt-showing-the-command-to-start-a-selenium-node-with-firefox-browsers-and-specific-configurations

Let’s now add a third Node with the Microsoft Edge browser.

Step 5: Configure Edge Browser in the Selenium Grid Setup

Open a new instance of the command prompt or terminal and run the following command:

The above command will configure three Edge browser sessions in a new Node on port 6163.

Let’s verify the addition of a new Node by navigating and checking http://localhost:4444.

command-to-configure-edge-browser-in-the-selenium-grid-setup-with-details-for-running-three-sessions-on-windows-11

Step 6: Configure a Distributed Grid

Each component is launched independently in a Distributed Grid setup, preferably on separate machines. Follow the following steps to configure the Distributed Grid:

  1. Start the Event Bus
  2. Open a new terminal or command prompt and run the following command to start the Event Bus. Event Bus helps in internal communication between different grid components.

  3. Start the New Session Queue
  4. Start the New Session Queue by adding the new session requests to a queue. The Distributor queries it. The following command should be run after opening a new command prompt:

  5. Start the Session Map
  6. Start the Session Map next, which will interact with the Event Bus and map session IDs to the Node where the session is running.

    Open a new command prompt and run the following command:

  7. Start the Distributor
  8. The next step is to start the Distributor which queries the New Session Queue for checking new session requests. When finding the matching capabilities, it assigns a Node to the New Session request.

    Open the command prompt and run the following command:

  9. Start the Router
  10. The next step is to start the Router, which will direct new session requests to the queue and route requests for active sessions to the Node handling that session.

    Open the command prompt and run the following command:

  11. Start the Nodes
  12. Start the Node to launch the browser sessions, which will eventually help run our automated tests.

    The following command will add one Node with four Chrome, Firefox, and Edge browser sessions. It will also spin one session of IE browser by default.

    Navigate to http://localhost:4444 and check the grid in fully functional mode.

    command-to-start-selenium-node-with-multiple-browser-sessions-including-chrome-firefox-edge-and-ie

    How to Perform Parallel Testing With Selenium Grid?

    It is time for parallel testing using the Selenium Grid setup. The tests will be run in parallel on Chrome, Firefox, and Edge browsers.

    Test Scenario:

    1. Navigate to the LambdaTest eCommerce Playground website.
    2. Search for a product using the search bar on the homepage.
    3. Check the page title of the search result page.

    Test Implementation:

    The BaseTest class is created to manage WebDriver instances for running tests on a Selenium Grid. This class is available in the seleniumgriddemo package in the src/test folder.

    github

    The ThreadLocal variable holds the RemoteWebDriver instance. Using ThreadLocal ensures that each thread gets its own instance of RemoteWebDriver that will help in parallel execution of tests seamlessly.

    The setup() method will take the name of the browser as a parameter and accordingly configure the browser for executing the tests. The name of the browser will be set on runtime using testng.xml file, as we are using the @Parameters annotation of TestNG for setting the browser name.

    diagram-illustrating-threadlocal-usage-with-remotewebdriver-for-parallel-test-execution

    The RemoteWebDriver instance will be instantiated using the Selenium Grid URL that runs on http://localhost:4444 and setting the capabilities of the respective browser option class.

    The capability se:name will show the test name instead of the session ID in the grid UI.

    The getDriver() method returns the RemoteWebDriver instance associated with the current thread.

    Similarly, the setDriver() method will assign the RemoteWebDriver instance to the current thread.

    The tearDown() method will call the quit() method on the RemoteWebDriver instance to close the session.

    A new test class named LocalGridDemoTests was created to implement the test scenario discussed earlier. This class extends the BaseTest class to use the configurations to run the test easily.

    The testSearchProduct() method will navigate to the LambdaTest eCommerce playground website, and the search box will be located on the home page using the Name locator in Selenium.

    Next, the test iPhone will be typed in the search box field, and the Search button will be clicked. The page header of the search result page will be asserted by getting its text using the tagName locator h1.

    Finally, the assertion will be performed to check that the text of the page header matches with the text that was used for searching the product. The word Search is added as a prefix before the expected search text, as this text appears as a static text on the page after anything is searched.

    Test Execution:

    The following testng.xml file is created for test execution purposes. This testng.xml will help us execute the tests in parallel.

    As mentioned, the browser names are passed using the parameter tag in the testng.xml file. Note that we will use the tag parallel to run the tests in parallel and provide the value as tests.

    This will run every test block available in the testng.xml file in parallel. The following is the screenshot of Selenium Grid UI showing the sessions running in parallel.

    screenshot-of-selenium-grid-ui-showing-sessions-running-in-parallel

    The following screenshot shows that the tests were executed successfully in parallel:

    screenshot-showing-successful-parallel-execution-of-tests

    Selenium Grid is one of the robust components of Selenium for configuring a local infrastructure for cross browser testing. However, there are certain limitations, and we would have to be specific while selecting the browser/browser versions and platforms for testing.

    Apart from what is set up in the grid, we need to configure an additional node to cater to our requirements. This could prove costly as we would be required to purchase new machines with a specific operating system, such as macOS or a particular version of Windows.

    This is where cloud platforms such as LambdaTest can be helpful as it saves us from the hassle of maintaining your Selenium Grid setup, so we could focus on writing better automation code. LambdaTest also empowers us with the ability of Selenium Grid for parallel execution, all on the cloud.

    Parallel Testing At Scale Using LambdaTest

    LambdaTest is an AI-powered test execution platform on the cloud that allows you to test your websites and web applications across 3000+ combinations of browsers, browser versions, and operating systems. It offers an online Selenium Grid to help you perform automation testing in parallel.

    Let’s try running our same test case on the LambdaTest cloud grid. The LambdaTest Automation Capabilities Generator can be used to configure the desired capabilities, which would save a lot of our time spent in Selenium Grid setup when done manually.

    Info Note

    Run Your Parallel Tests Across 3000+ Real Desktop Browsers. Try LambdaTest Today!

    Test Implementation:

    With LambdaTest, we only need to create a RemoteWebDriver session using the Remote Server URL, add the LambdaTest Username, Access Key, and the grid URL in the script along with the automation capabilities, and then we are good to go.

    A new package named lambdatestgriddemoTests is created in the src/test folder. A new test class, LambdaTestGridDemoTests, uses the same testSearchProduct() method.

    lambdatest-ai-powered-test-execution-platform-showing-parallel-testing-on-cloud

    This test class is extended by the BaseTest class, which holds all the configuration methods for running tests on the LambdaTest cloud grid.

    A new BaseTest class is created to handle the configurations:

    The RemoteWebDriver instance is held by the ThreadLocal variable. It ensures that each thread gets its instance of RemoteWebDriver, allowing thread safety to perform parallel execution of the tests.

    The browser name, version, and platform name will be provided on run time through the testng.xml file, as @Parameter annotation from TestNG is used to set it. The LambdaTest Username and Access Key will be fetched from the environment variable.

    There are multiple if statements in the setup() method that carries conditions for starting the browser using a RemoteWebDriver instance with the specific version on the platform. The methods getChromeOptions(), getFirefoxOptions(), and getEdgeOptions() will set the capabilities for starting the browser on the cloud.

    Similarly, the ltOptions() method will set all the common capabilities required for running the tests on the LambdaTest cloud grid.

    Test Execution:

    The following testng.xml file will allow us to run the automated tests in parallel on different browser/platform combinations.

    The browser, browser version, and platform values are provided using the testng.xml file. This makes things easier if we just want to add more browser/platform combinations to run the cross-browser tests.

    The following screenshot from IntelliJ IDE shows the successful execution of the tests:

    screenshot-of-intellij-ide-displaying-successful-test-execution

    The test execution details can be viewed on the LambdaTest Web Automation dashboard:

    screenshot-of-lambdatest-web-automation-dashboard-showing-test-execution-details

    Conclusion

    Selenium Grid setup, if done manually, could be challenging. Selenium testing on a cloud-based grid helps us run tests in parallel and test on a different configuration; the same can be performed on LambdaTest without investing time and resources to configure Selenium Grid.

    Try it once by running your automated tests on this online grid, and let us know your feedback in the comment box.

    Frequently Asked Questions (FAQs)

    How to set up Selenium Grid 4?

    You can set up Selenium Grid 4 by downloading the latest version of Selenium Server and configuring the Hub and Node through the command line using Java commands.

    What is Selenium Grid used for?

    Selenium Grid runs multiple tests across different browsers, operating systems, and machines simultaneously, which helps reduce the execution time of test suites.

    What is the configuration file for Selenium Grid?

    The configuration file for Selenium Grid is a YAML or JSON file that specifies the roles, browser types, maximum instances, and other configurations for Nodes in the grid.

    How to handle the grid in Selenium?

    Handling Selenium Grid involves setting up the grid environment, configuring Nodes, writing tests, and communicating with the Hub to allocate browser instances across the available Nodes.

Author Profile Author Profile Author Profile

Author’s Profile

Faisal Khatri

Faisal is a Software Testing Professional having 14+ years of experience in automation as well as manual testing. He is a QA, freelancer, blogger and open source contributor. He loves learning new tools and technologies and sharing his experience by writing blogs.

Blogs: 30



linkedintwitter