Using Containerization within Your Test Automation Solution

Test automation has become the foremost way agile software development teams are ensuring the code that is deployed meets their quality standards. The selection of automation tools is nearly limitless, with a wide array of supported programming languages, open-sourced or proprietary software, that can meet the technical needs of large or small projects looking to minimize cost and time needed to deploy code.

Why do agile teams depend on test automation and how are they looking to mitigate its shortcomings? It’s common knowledge that test automation is now essential for successful DevOps. With repeatable, static, automated test scripts in place to check the sanity of new releases, some organizations are now able to deploy code to production more rapidly then ever before. We also see that organizations – while operating within so many different environments and platforms – are looking for innovative ways to improve test efficiency, execution times, compatibility with continuous integration tools, and general usability.

This is where automation has also met some of its biggest criticism. While the technology driving automation forward is progressing daily, the tools used are not always in step with development teams and their typical workflow – whether it’s which platforms the application is developed for or how they are continuously integrated. This can lead to test fragmentation, difficult maintenance, loss of simplicity, as well as compatibility issues across DevOps processes. As automation solutions become more robust, so does the challenge of efficiently running tests across a wide range of devices, browsers, environments, and even segments of the application under test in the quickest amount of time possible.

Until recently, concurrent automation, often called ‘Distributed Testing’ has required separate machines (either virtual of physical) running as nodes for a central hub that drives the automation. This can lead to massive overhead depending on the importance of diverse platforms your automation needs to cover. Not only are there concerns about keeping several machines running up to spec and operational, the resources required to do so often exceed budgets and lead to automated test efforts minimizing the platform or scope of what they really ought to be testing. Within the last few years, containerization has emerged as a truly viable answer to this problem.

Containers, as it turns out, are often mistaken for ‘Lightweight Virtual Machines’, but they’re more like processes; something that can run concurrently on a single host or operating system. A developer of Docker, one of the leading container tools today, coined an insightful analogy. He says to think of a VM as a house, and container as an apartment:

“Houses (the VMs) are fully self-contained and offer protection from unwanted guests. They also each possess their own infrastructure – plumbing, heating, electrical, etc. Furthermore, in the vast majority of cases houses are all going to have at a minimum a bedroom, living area, bathroom, and kitchen. I’ve yet to ever find a 'studio house' – even if I buy the smallest house I may end up buying more than I need because that’s just how houses are built…

“Apartments (the containers) also offer protection from unwanted guests, but they are built around shared infrastructure. The apartment building (Docker Host) shares plumbing, heating, electrical, etc. Additionally, apartments are offered in all kinds of different sizes – studio to multi-bedroom penthouse. You’re only renting exactly what you need. Finally, just like houses, apartments have front doors that lock to keep out unwanted guests.”

(Mike Coleman, Docker Developer, https://blog.docker.com/2016/03/containers-are-not-vms/)

For this reason, it was almost destined that test automation engineers would begin to integrate Selenium and Selenium Grid into Docker, which has created a truly unique method of cross-platform testing with far less infrastructure requirements for their CI solution, as well as a lower cost than commercial cloud-based solutions like Saucelabs or Browserstack. Today, there are very active discussions on Github and other online channels outlining how to achieve Saucelab-type results with Docker and Selenium grid. Each day, developers and test engineers are constantly pushing the boundaries of distributed testing (and Docker itself) while proving the utility of containers within their frameworks. The future appears to be very promising, with a growing number of companies investing in automation solutions built on this concept.