Selenium is nowadays an indisputable standard in browser automation. Its architecture is well-known and all popular browsers are supported out of the box. More than that commercial companies provide Selenium infrastructure as a paid service. But is it comfortable to use Selenium server on developer’s machine?

Problem

Being web-application developer or QA automation engineer you can face the following inconveniences in your experience with Selenium server:

  1. It is complicated to install and use multiple versions of the same browser. Binary packages normally allow only one active browser version. Selenium or its web drivers normally search browser binaries in some predefined paths. So trust me — it is difficult.
  2. If you are using Selenium to launch a browser from your operating system — it clutters your disk with cache and other temporary files.
  3. More than that you can’t guarantee that browser settings remain in the same state like it was after fresh installation. For example you can accidentally change proxy server or security settings. This can lead to broken tests.
  4. Difficult to run several tests in parallel in multiple browsers. Trying to do this causes different issues with window focus: not firing events, unexpected CSS styles and so on.
  5. Need to know browser versions compatible to installed Selenium version. The same problem occurs with webdriver binaries.

Introducing Selenoid

In my previous article (part I, part II) I briefly described new open-source Selenium tools: Ggr and Selenoid. Ggr is mainly used to organize large Selenium clusters and is not needed to use Selenium on your computer. What I am going to talk about is Selenoid — an alternative lightweight Selenium hub implementation that launches browsers in Docker containers.

Installation

Having said that let me show how easy and user-friendly Selenoid is. To start using it you need to complete 3 short steps:

  1. Create Selenoid configuration directory and generate configuration file:
# mkdir -p /etc/selenoid# docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aerokube/cm:1.0.0 selenoid --last-versions 2 --tmpfs 128 --pull \
> /etc/selenoid/browsers.json
# docker run -d --name selenoid -p 4444:4444 \
-v /etc/selenoid:/etc/selenoid:ro \
-v /var/run/docker.sock:/var/run/docker.sock \
aerokube/selenoid:1.1.1
http://localhost:4444/wd/hub

User interface and statistics

Selenoid can be used in conjunction with Ggr to organize large Selenium clusters. This is why it does not have any user interface like Grid Console in original Selenium. You can view browser consumption in two different ways:

# docker run -d --name selenoid-ui --net host \
aerokube/selenoid-ui:1.0.0
http://localhost:4444/status
$ curl http://localhost:4444/status
{
"total": 80,
"used": 14,
"queued": 0,
"pending": 1,
"browsers": {
"firefox": {
"46.0": {
"user1": 5,
"user2": 6
},
"48.0": {
"user2": 3
}
}
}
}

Ready to use containers with browsers

That is good to have a tool that automatically starts containers with different browsers for you. But that’s even better to have ready to use containers with various browser versions. We did an effort and packed a lot of different versions of Firefox, Chrome and Opera in containers. You can see all available containers on selenoid@DockerHub.

# docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aerokube/cm:1.0.0 selenoid --last-versions 2 --tmpfs 128 --pull \
> /etc/selenoid/browsers.json
# docker kill -s HUP selenoid
screenResolution: 1280x1024x24

Conclusion

In this article I demonstrated how to efficiently orchestrate different Selenium browsers. Trust me — Selenium can be painless. If you are interested in efficient software testing infrastructure — find more open-source tools in our Github or follow us on @aerokube.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store