97 Things Every Java Programmer Should Know

Chapter 86. Unlocking the Hidden Potential of Integration Testing Using Containers

Kevin Wittek

Most Java developers have probably encountered the testing pyramid at one point in their career, whether as part of a computer science curriculum or mentioned in conference talks, articles, or blog posts. We can find a multitude of origin stories and variations of this metaphor (with a deep dive into those worthy of an article on its own) but, in general, it boils down to having a sizeable foundation of unit tests, followed by a smaller chunk of integration tests on top of that, and an even smaller tip of end-to-end UI tests.

This shape is proposed as an ideally optimal ratio of the different test classes. However, as with everything in software and computers, these guidelines need to be assessed in context, which means assuming integration tests to be slow and brittle. And this assumption is probably true if integration tests are expected to be run in a shared testing environment or require an extensive setup of local dependencies. But would the ideal shape still be a pyramid if we challenge these assumptions?

With ever more powerful machines, we can either use virtual machines (VMs) to wholly contain the complete development environment or use them to manage and run the external dependencies necessary for integration testing (such as databases or message brokers). But since most VM ...