Container Assisted Testing
TL;DR: Why mock if you can have the real thing? Containers are here to help you testing the real thing across environments.
As if we wouldn’t have enough acronyms flying around in the software testing arena. Oh my. Let’s add one more, shall we? I promise it has a purpose and will make your life easier.
Enter Container Assisted Testing (CAT):
The idea with CAT is that in unit and integration tests—rather than mocking out a dependency—you run the real thing in a container.
Sounds to theoretical? Turns out we’ve been doing it for a while now—I had to dig a bit but I did eventually find the SO answer I gave in early 2016:
How could i write unit tests for an application that uses influx db as database without installing influxDB on system…stackoverflow.com
OK Michael. Enough general statements. Gimme a concrete example!
Glad you asked. Let’s say your code needs to interact with etcd. In order to test your code, you could simply do the following:
As you can see in the code snippet above (taken from ReShifter discovery package), you simply launch etcd as a container (line 24), carry out your tests and tear it down again (line 21) when you’re done. Since containers, once the image is pulled and available on the machine, launch so wickedly fast, the actual overhead is minimal.
For example, when I save the discovery.go file in my Atom editor the respective unit tests are automatically executed, taking around 15 sec. Mind you, the majority of the time is spent in the tests, not the ramping up/tearing down of the etcd container.
Right, you’ve convinced me, Michael. Can you talk about pros and cons of CAT a bit?
Sure. CAT has the following characteristics:
- You can use it offline (on your laptop, locally) as well as in the cloud
- It introduces a little overhead (finding/preparing the container images, setup, runtime) but you get the real thing in exchange, no limited mocked stuff
- Not all things can be covered easily. For example, an entire stack or platform such as AWS. There are however attempts to address this, see, for example, atlassian/localstack.
Hope you find CAT as useful as I do and next time you find yourself mocking something for a unit test, maybe ask yourself if CAT is an option.
— — —
UPDATE [2017–07–01]: As pointed out by user jstoj over on Lobste.rs, in the context of microservices, with many containers to start, CAT may potentially be very slow, i.e. the testing cycles go up from the ms range to the seconds range, so please do consider this as well.