Selenium is a popular tool for end-to-end testing of web-apps. It’s grid capability allows to have fast test executions, across multiple browsers, in parallel. However, the setup of such environment is always an issue to deal with. That is why, for our setup of Selenium Grid, we decided to use Docker containers to standardize the creation of the Hub and Nodes. This allowed us to have nodes that can be easily re-built, are source-controlled, re-usable and isolated from each other. Additionally, we had special issues come up when working with Safari and IE.
This article is intended as a general reference to follow along to, in order to easily set up a new Selenium grid with Docker, condensing everything we learned during the process. We also give some insight on SE-Interpreter, (the tool we decided to use to communicate with the Selenium Grid) – as to why we chose it and what benefits it has.
Selenium-grid Organization Diagram
Our Selenium Grid currently supports all 4 major browsers through Docker containers and VMs. Our Chrome and Firefox instances are the most used, so the containers for them are ready to be instantiated at any moment. Having 8 of them ensures a quick execution, given that deployments do not happen too often (unlike regular builds on commits/push).
For the Safari and IE nodes, these are run a bit less frequently then Chrome and Firefox, only for compatibility validation, so 1 VM for each one suffices.
.png)
Selenium nodes as Docker containers: Adding nodes on-demand
It becomes too time-consuming to set up and maintain VM’s for each selenium instance assigned to a specific browser, so instead, we decided to have them using Docker containers. These can be maintained through source-controlled code, and can be instantiated as needed. It also helps solve yet another one of the many problems of UI tests, that they are often slow to run. Adding temporary Docker containers helps reduce execution time and can be destroyed when not in full use. The containers can also be used locally during the development of new tests, that way the Selenium Grid is always free to run product deployments.
