Selenium in 60 seconds

I present to you the translation of my article on Medium.com.

Selenium today is the de facto standard for automating the execution of tests in browsers. All popular browsers are supported out of the box, and the architecture is well known. There are even companies that provide Selenium for money. But is the usual Selenium server convenient for local debugging tests?

Problem

As a web developer or test automation engineer, you may encounter the following inconveniences when working with a standard Selenium server:

1. You need to install several different browsers on your computer. In normal life, you usually use one browser, for example, Chrome, but you have to install Firefox and Opera yourself in order to debug Selenium tests in them.
2. It is difficult to install and use multiple versions of the same browser. If you install the browser from packages, then generally you can have only one installed version. In addition, Selenium and its web drivers usually search for a browser executable file along a specific path. Therefore, believe me, using multiple versions can be a difficult task.
3. If you launch the browser installed on your operating system, it will fill up disk space with its temporary files and cache contents.
4. You cannot guarantee that your browser settings will always remain in the same state as after a clean installation. For example, you can accidentally change the address of the proxy server or security settings. This may lead to a drop in previously running tests.
5. It is difficult to run multiple tests in different browsers in parallel. Attempting to do this usually leads to various problems: windows start to compete for focus, non-triggered events, not expected CSS styles, and so on.
6. You need to know which version of Selenium is compatible with which version of the browser. The same is true for web driver executables (for example, Chromedriver).

The above list of flaws is far from complete. But let's dwell on this and try a much more convenient way of debugging Selenium tests locally.

Selenoid

In my previous article ( Part I , Part II ) I briefly described the new open tools for working with Selenium: Ggr and Selenoid . Ggr is mainly needed for large Selenium clusters and is not needed for debugging tests on your machine. Today I will talk in more detail about Selenoid , an alternative implementation of the Selenium hub that launches browsers in Docker containers.

But why launching browsers in containers is so convenient? And what is the difference between launching browsers from containers supplied by the developers of Selenium and Selenoid? - The main idea of ​​Selenoid is to launch a new container for each Selenium session (i.e., request a new browser) and stop them immediately after the session is closed. This approach immediately solves all the problems associated with sticking states in the caches and using the same browser settings in different sessions. Each container contains a specific version of the browser, the correct version of the web driver or Selenium server that supports this browser and all dependencies like fonts, graphics libraries, and so on. Moreover, containers provide a sufficient level of isolation for browser processes. This allows you to run an unlimited number of different versions of browsers in parallel and forget about problems with focus. Of course, these same problems are solved with conventional Selenium containers. But in order to get behavior similar to Selenoid, in addition to Docker, it is usually required to use complex admin tools like Ansible or Salt .

Installation

Having a little advertised Selenoid, it is time to show how easy it is to work with it. In order to get a working Selenium, you need to perform 3 short steps:

1. Install Docker . This is usually done using a standard package manager for your operating system such as APT , Yum or Homebrew . Details can be found in the Docker documentation .

   
   

2. Create a directory to store the Selenoid configuration and generate a 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 

   
   

   The last command also downloads the Docker containers images of the two latest versions of Firefox, Chrome and Opera and generates the correct configuration file for Selenoid.

   
   
3. Run Selenoid:

 # 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 

All - 60 seconds have passed and Selenoid is ready to go. No need to install Java and download Selenium by hand. Just run your tests using the same URL as the regular Selenium server:

 http://localhost:4444/wd/hub 

Mordochka and statistics collection

Selenoid can be used in conjunction with Ggr to configure a large Selenium cluster, so it does not have a graphical interface like the Grid Console in a regular Selenium. You can view browser consumption in two ways:

I. Launch an additional lightweight container with a Selenoid UI. This is done by the command:

 # docker run -d --name selenoid-ui --net host aerokube/selenoid-ui:1.0.0 

The muzzle will be available in the browser at http://localhost:8080/ :

Ii. Send Selenoid statistics to the external system: Graphite , InfluxDB , ElasticSearch, and so on. Selenoid statistics can be obtained at the following URL:

 http://localhost:4444/status 

Data is sent as JSON in the following format:

  $ 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 } } } } 

Selenoid returns how many containers can be started simultaneously ( total ), how many are currently running ( used ), how many requests are waiting in the queue ( queued ) and how many containers are still being started ( pending ). The browsers element contains information about the consumption of browsers by various users. The username is retrieved from the Basic HTTP headers, if they are set or set to unknown , if not. Although you can parse the JSON shown manually using a script, we recommend using Telegraf for this purpose. More information on how to use Telegraf is outlined in this section of our documentation.

Ready containers with browsers

Agree, it's cool to have a tool that automatically launches containers with different browsers. But it's even cooler to have a set of ready-made containers with different versions of popular browsers. We have done a lot of work and prepared images of containers with different versions of Firefox, Chrome and Opera. The complete list can be viewed on selenoid @ DockerHub .

To always have a set of fresh versions of browsers, you only need to occasionally run the command:

 # 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 

This command automatically downloads the latest container versions and generates a new JSON configuration for Selenoid. To start using new browsers, send Selenoid a command to re-read the configuration (you can do it under load):

 # docker kill -s HUP selenoid 

Our containers also support the ability to set arbitrarily screen resolutions (by default 1920x1080x24 ). To set the resolution, just pass the screenResolution capability:

 screenResolution: "1280x1024x24" 

Conclusion

In this article, I explained how to effectively manage various browsers with the help of Selenoid. Believe me - work with Selenium can be comfortable. If you are interested in building an effective testing infrastructure, you can take a look at other open tools in our organization on Github or subscribe to our Twitter account @aerokube .

In gratitude to the author of a wonderful picture, see how it was painted .