The testing pyramid

What it is

The testing pyramid concept, which came about in 2003-2009 according to Martin Fowler’s blog, is basically a guide for what the ratio of your different automated test types should be. The highest quantity of tests should be the unit layer, at the lowest level of the pyramid, with integration/UI tests being smaller in number at higher pyramid layers.

Why it matters

I’ve found this to be a useful guide in my career and in particular, I think applying it in a pragmatic way can be powerful. Unit tests can be run very quickly (here is where most of the ‘bugs’ are) and when written properly, the clean implementation code they enforce are results you can’t get later if you postpone them.

Avoiding pitfalls

The difference between unit tests and higher level tests can be grey at times. I think it’s important to not get too far into semantics over exactly what type a given test falls under but focus on writing the tests! Some unit tests may push that limit and look like integration tests. Having absolute purity there is not important. What is important is having a test suite under your control that can provide quick feedback and keep your code base clean. Over time, you can get a better feel for which tests are brittle and how you can rearrange your layers in an optimal manner.