Testing the Right Things with Docker

Fast and efficient software testing is easy with Docker, says Laura Frank of Codeship, who will be presenting a talk called “Building Efficient Parallel Testing Platforms with Docker” at LinuxCon + ContainerCon Europe next month.

In her talk, Frank will explain how containers can be used to maintain parity across development, testing, and production environments as well as to reduce testing time. We spoke with Frank to get a preview of her talk along with some real-world testing advice.

Laura Frank: Containers generally have a much lower overhead than traditional VMs, meaning they start a lot faster and use less resources. Instead of waiting a minute for your testing environment to fire up, you could have the same environment up and running in maybe 10 seconds if the services are running inside containers. Multiplied over a workday and across an engineering team, that's a huge productivity boost.

Aside from the actual time of booting up a testing environment, using Docker can allow you to process testing workloads across containers in a distributed environment. Containerization enables lots of interesting architecture patterns, like creating a parallel testing platform, that can have a lot of performance benefits.

Linux.com: What tools does Docker specifically provide to help with testing?

Laura: Docker Compose, Docker Registry, and Docker for Mac and Windows are the tools that individual developers will interact most with when it comes to testing. Compose allows you to create an application template, so you can start all of the services in your application in containers with just one command. From there, the Registry allows for easy distribution of application images, which makes moving code from dev to test to prod pretty simple. And since Docker for Mac and Windows is now publicly available, non-Linux users can benefit from all of the Docker tools without having to ssh into a remote box, or even use VirtualBox on their local system. The last year has been full of tooling improvements for the individual developer.

Linux.com: How does Docker help maintain parity?

Laura: The simplest way to maintain parity is by ensuring all components and dependencies are identical in each environment. With Docker, you have an image and can start a container from that image. It's going to be the same no matter where it's running, whether it's on your local machine or on a AWS instance.

Linux.com: Can you describe a real-world scenario?

Laura: Lots of companies use Docker, and you might have an application running in production that runs in Docker containers, whether it's a small web app or something complex using Kubernetes. In the best case, your local development environment is an exact replica of what's running in production. But it wasn't always the case that engineers used Docker in their everyday development workflow, though it's becoming easier now because of the developer tools that Docker created, like Docker Compose.

What's more uncommon is that the testing or QA step is also using Docker. Maybe the developer doesn't run tests inside a container during local development, and maybe the CI or build system doesn't support Docker. This leads to a mismatch between environments, and no guarantee that if it builds in CI, it will work as expected in production.

Linux.com: What are some potential pitfalls to look out for? And what advice do you have for testers?

Laura: Testing is a great way to tell if your code is broken, but it doesn't guarantee that your code is working as intended. The absence of test failures doesn't mean that everything is perfect, because that metric is dependent on the quality of your tests. Don't get a false sense of security by a green build. You really have to invest time making sure you're testing the right things, and testing the things right.