The nuts and bolts of the Docker-Selenium project

by Lauri Apple - 1 Jun 2016

Many teams at Zalando have been using Docker-Selenium: A project that aims to provide Selenium inside a Docker container with Chrome and Firefox. Leo Gallucci, Docker-Selenium’s creator and an engineer on our Test Infrastructure team, sat down with Zalando Open Source Evangelist Lauri Apple to take a closer look at his two-year-old project.

Lauri Apple: Why did you create Docker-Selenium?

Leo Gallucci: I started the project while I was working at AppNexus, where I was in charge of building and maintaining the test automation suite of an AngularJS project. I was also doing DevOps tasks related to the test infrastructure.

The objective was to run the tests headless. Different solutions existed for that (e.g. PhantomJS), but we needed real browsers like Chrome or Firefox to run our tests on. One reason was to get better test confidence, while the other was that Protractor doesn't play nice with PhantomJS.

With Selenium, you can always run your tests locally—but as soon as your tests run, the browser pops up in your main display, which can be annoying. You could configure your windows manager to move it automatically to another workspace, and similar, other solutions exist—but why bother going to all that trouble if you can just docker run selenium?

You can also configure a headless Xvfb selenium, as it is a common use case in Jenkins CI. But again: Why bother going to the trouble, now that Docker exists?

Lauri Apple: How did you build Docker-Selenium, and how does it run tests?

Leo Gallucci: It has tests that run seamlessly and locally or in Travis, plus deploy automation using TravisCI Docker infrastructure.

The reason for pushing new releases (Docker images) from Travis instead of using Docker automated builds is that a CI tool allows running arbitrary scripting like tests before pushing a broken image. See issue 208 for an example.

Lauri Apple: Have you actively promoted the project, or have people just learned of it in passing?

Leo Gallucci: There was no promotion in the beginning. I suppose the success of it is due to the fact that it is an obvious use case for any developer that needs Selenium and knows how handy Docker technology can be when it comes to working with disposable infrastructure.

Automation testers probably search for two words, selenium and docker, then the top results are the official project followed by this one. Sometimes it’s the other way around depending on Google’s mood.

Lauri Apple: How did you get the teams at Zalando using it? What was your pitch?

Leo Gallucci: When I started at Zalando in March 2015, we weren’t working with Sauce Labs’ Selenium Grid yet. We only had a centralised Selenium Grid in our data center, which acted as a kind of SPOF (Single Point of Failure) for our Zalando teams. You couldn't see the tests running or have recorded video results, which are two features of docker-selenium. Sure, Sauce Labs offers these same features and supports hundreds of browser combinations. But while it’s often the preferred option for frontend testing infrastructure these days, Docker-Selenium has three distinct advantages:

  • Cost: Free
  • Speed: Runs around 2x faster than a paid, cloud-based Selenium solution
  • Security: No need to tunnel your local app to a third party cloud solution.

Docker-Selenium is used by a multitude of companies, including Nvidia and Algolia. The popularity of the project has also grown, where we saw a spike in use after one of our contributors, @rubytester, conducted a presentation back in September 2015. Most users come from Google search results, as shown in the traffic stats.

When Matthew Smith (aka @mtscout6) jumped into the project four months after its creation, great things happened. He made a few interesting improvements, but moreover, we started conversations about moving Docker-Selenium to the official SeleniumHQ organisation. Matt pushed this and contacted the Mozilla team. Later on, I decided to continue maintaining my own hosted project with differentiated features, which is why two projects for the same purpose exist today.

Lauri Apple: What is the future of this project?

Leo Gallucci: People tend to build long-running Selenium grids by using the stock Docker Selenium images or my own separately maintained version. However, when you see the Sauce Labs or BrowserStack approach, you realise that the way to go is isolation, i.e. one machine, VM or Docker container for each Selenium session. This gives us an idea for the next steps for the project. We might want to add a Jenkins plugin. We also want to automate new version detection — e.g., a new version of Chrome/Firefox/Selenium.

As already mentioned, Docker-Selenium is an open source project, so we’re always looking for contributors. The more users, the merrier!

To hear more about Docker-Selenium, Leo and Diego Molina will present the project at the next Berlin Selenium Meetup, hosted by Zalando Tech on July 20. Register at the Selenium Meetup page today.

Similar blog posts