Selenium-Grid is a method of testing using Selenium that enables simultaneous testing on different devices running different operating systems and browsers; basically a number of machines running multiple tests in parallel. Selenium Grid has two versions at the moment – Grid 1 and Grid 2 – but the newer Grid 2 is now more widely used. It has been designed to follow a hub and node fashion, where a single device known as the hub runs the test, and the nodes are constituted of various other machines that do the execution. Selenium-Grid supports distributed test execution. Maintaining Selenium Grid Infrastructure Simplify the management of the Selenium Grid Nodes and stabilize said nodes by cleaning up the test environment after the build has been completed
- Shutdown hub (with lifecycle manager)
- Daily reboot your nodes (autostart server on boot)
- Place all the executables/scripts on a central file share (for easy updating)
- Restart hub and take Jenkins out of shutdown mode
- Finish all the tests (Put Jenkins in shutdown mode to prevent starting of new tests)
How do you control Selenium Grid failures w.r.to browser auto updates?
- Disabling auto upgrade
- Have specific node for the specific version of a browser
- Create a static environment.
Limitations & Challenges Using Selenium Grid
Maintenance is expensive–Need to maintain the health of other computer systems which run all the nodes. Certain third party libraries have limitations that prevent them from being used in conjunction with Grid.
- Java process –will eventually run out-of-memory.
- Nodes in Selenium Grid often end up in a bad state if left up and running for a long enough time.
- Manually restarting the nodes in case of issues.
- The performance of Selenium Grid is very low in case of a large number of node servers.
- Scalability issues
Advanced Selenium Grid –Next level Scalability
It’s cheaper to just run your tests against Sauce Labs or Browser Stack or Testing Bot because maintaining your own Grid and a lot of different browsers and operating systems can be very time-consuming Selenium Grid + Docker or Docket Compose
- By using docker, we could reduce the significant amount of effort in setting them up the selenium grid.
- We can bring this infrastructure up and down anytime by issuing a single command and It is highly scalable as well.
- Another added benefit to running Selenium Grid with Docker is the ability to restart the entire grid in just a couple of minutes.
Docker: What is the use of docker here? Docker is a bit like a virtual machine. But unlike a virtual machine, rather than creating a whole virtual operating system, Docker allows applications to use the same Linux kernel as the system that they’re running on and only requires applications be shipped with things not already running on the host computer. This gives a significant performance boost and reduces the size of the application – source: opensource.com Docker is a manager of Infrastructure. It will be able to package a software and all its dependencies to run as a container. You can deploy the software, packaged as a docker image, in any machine where docker is installed. It, kind of, separate the software from the hardware – so the developer/test engineer can rest assured that the application will run on any machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code. Managing selenium grid infrastructure was a pain. By using docker, we could reduce the significant amount of effort in setting them up the selenium grid. We can bring this infrastructure up and down anytime by issuing a single command and It is highly scalable as well. However, there is a dependency that this dockerized selenium grid should be up and be running before you start tests. Once we are done with our tests, we do not have to keep the grid up and running. Currently, as per this approach – this is managed outside the framework – either manually or some automated script.