This blog post is the third blog post about UI test with Selenium. In the previous blog, we looked at Selenium Grid and how it can help you in executing browser tests using real browsers. Unfortunately, running a Selenium Grid also has some downsides, like the need for quite some infrastructure and maintenance. In this blog, we’ll take a look at Docker and see how we can use it to overcome some of these downsides.

Originally started as an internal project within the Cloud provider dotCloud, Docker was released as open source in March 2013. Since about a year, Docker really got some attention from the public and became quite popular. Docker is a tool that allows applications with their dependencies to run inside a  virtual environment called a container. The images from which a container is created can be scripted and subsequently built in an automatic way. The scripts can be put in version control alongside your source code so that you have the same benefits as you have with source code.

Unlike Virtual Machines (and physical machines of course), a container doesn’t need it’s own operating system. This makes containers relatively small in size. Also the hardware requirements are much lower, since it only needs memory and CPU power to run the application, not an application and a guest operating system. Finally, the startup time is much lower because you don’t need to boot up an operating system before you can start your application which normally takes up to a couple a minutes.

selenium docker app isolation

So Docker is a great platform to run you application on. However, the architecture of your application has to be fit for it to be really beneficial. If you have a big monolith, chances are that it will be difficult to containerize and you’ll not get all the advantages. But if you have a micro services architecture, it will be easy and fast to provision your services and scale up or down as needed.

But there’s another way to use Docker: we can also use in in our deployment pipeline. In the previous blog post, we saw that having a permanent and shared Selenium Grid is not ideal, and that we rather start with a new and dedicated Grid every time we start a test run. Using physical machines of virtual machines, this is really impractical due to long startup times and hardware requirements. But if we use use Docker to create a grid, we don’t have these downsides. It’s the same as using disposable dish ware: instead of putting effort into maintaining it in good shape (by cleaning the dishes), you just throw it away once you’re done with it. In the case of Selenium Grid: we just start some containers containing the Grid when needed and stop them when they are not needed anymore!

In the next blog post, we’ll see how to configure such an on-demand Selenium Grid using Docker and take a look at Docker Hub.


This blog was written by Harm Pauw.

Scrum causes more change for developers than you might think!


Please enter your comment!
Please enter your name here