Add Some "Docker" To Your Testing - Live from #AgileTD

I am one of those people. I use Docker. It's part of our infrastructure. I get the basics of containerization. I can start an instance, I can do work in them. That's all well and good, but how much do I know vs. how much do I just think I know? When I saw a session titled "Using Docker for Testing", I figured now was as good a time as any to see how much I actually knew about Docker and whether or not I could pick up some new things (the answer, to save you all some suspense, is "of course" ;) ).

first off, what is Docker specifically? Docker is one of a number of "container" technologies available. Containers allow you to package an application, with all of its dependencies, into a standardized unit for software development and testing. What that ultimately means is that a container is able to load an environment, and it should run the same way each time. the nice thing is that you don't necessarily need to know the machine internals to be able to share an app with others.

One of the nice implementations of Docker and a very helpful one in my work is that we use Docker to containerize our testing environments for automated tests, as well as our development environments and our customer appliances. The beauty of this is that we can create a variety of parallel machines, and we can run tests in a number of containers that can be set up rapidly and destroyed as soon as we finish. Instead of building machines from the ground up each time, we can open as many Docker hosts as we need, which helps make our tests run faster.

The tricky stuff starts to happen when we want to run multiple test runs, or with multiple different release versions, or some variety of tests that require a variety of machines. Here's where having a variety of docker containers help provide interchangeability.  Jenkins provides a variety of Docker plugins that allow the user to be able to create new containers and destroy them after jobs are completed. Additionally, the containers can be created completely independent from any other job, and can be used with any slave, or can be called uniquely/individually.

One of the interesting approaches that can be used is to create a container that has Selenium, the app you want to test, and the configuration options so that the tests are run with the browser you intend to target. All of it is in the respective containers. One of the options for running across multiple hosts is a tool called Kubernetes. Kubernetes starts multiple nodes which in turn allocate container to nodes. It's an interesting paradigm, and worth looking into.