Long Live The Testing Pyramid

Ramona is a seasoned software engineer with a strong background in quality assurance. She possesses a dual perspective on the product, both as a tester and a developer. Ramona's primary focus is... More about Ramona ↬

Receive weekly insights on front-end and UX, trusted by over 200,000 individuals.

A respected peer of mine, Jan Philip Pietrczyk, once shared his thoughts on the developer's duty to write functional code:

His words have had a lasting impact on me as they place our code within the context of those who depend on it. In our fast-paced society, users trust that we produce the highest quality code and that our software "simply" operates. Meeting this level of trust is undoubtedly challenging, which is why testing is such a vital component of any development stack. Testing a process assesses the quality of our work, validating it against various scenarios to help pinpoint issues before they escalate.

The Test Pyramid is one of many testing strategies. Although it has been the dominant testing model for most of the past decade since its introduction in 2012, I don't see it mentioned as frequently as before. Is it still the preferred method for testing? Numerous other strategies have emerged since then, so has the Test Pyramid been overshadowed by newer models that are more suitable for current development practices?

This is what I aim to investigate.

Building trust with users necessitates a solid testing strategy to ensure that the code we write makes the product function as they anticipate. Where do we begin when writing a good test? How many tests do we need? This question has puzzled many. However, it was a brief remark by Kent C. Dodds that provided the clarity I needed:

That's the starting point! Determining the testing goal is the most critical aspect of a testing strategy. The internet is rife with memes depicting poor decisions, many of which stem from a lack of understanding of the purpose of a specific test and the number needed to instill confidence. In testing, there is a "right ratio" to ensure that code is adequately tested and functions as intended.

2 unit tests. 0 integration tests. pic.twitter.com/K2MZKwr8JT

The issue is that many developers concentrate solely on one type of testing, typically unit test coverage, without a strategy for how different units interact. For instance, when testing a sink, we might have coverage for testing the faucet and the drain separately, but do they function together? If the drain is blocked but the faucet continues to run, things aren't exactly working, even if unit tests indicate the faucet is.

Testing approaches are often depicted in terms of shapes, as we've already seen with the pyramid model. In this article, I want to share some of the shapes I've noticed, how they've manifested in real-world situations, and finally, which testing strategy meets my personal criteria for good test coverage in current development practices.

Introducing Image Optimization, Addy Osmani's new practical guide to optimizing and delivering high-quality images on the web. Everything you need in a single 528-page book.

Before we proceed, let's revisit some common definitions of different test types to jog our memories:

So, how should these types of testing interact? The Test Pyramid has traditionally been the metaphor we've relied on to integrate these various types of testing into a comprehensive testing suite for any application.

The Test Pyramid, first introduced by Mike Cohn in his book Succeeding with Agile, and further developed by Martin Fowler in his "The Practical Test Pyramid" post, prioritizes tests based on their performance and cost. It suggests writing...