Shapes don’t matter

Pyramids, trophies, quadrants, ice cream cones; if you care it’s because you’re doing it wrong

I first learned about the testing trophy five years ago from a front-end architect/developer who was trying to sell me on the notion that it was somehow better than the test pyramid. And while I’ll admit that including static checking is a grand idea, the pyramid never explicitly excludes it. However, there’s a deep problem hidden in the test trophy, which is that JS developers are attempting to disguise their laziness as a best practices pattern. By this I mean that JS developers love their anonymous arrow functions. Despite their being very little support for their continued use of anonymous arrow functions (sometimes referred to inaccurately as callbacks) over namedspaced functions, they continue to be used because they benefit the developer. I’d argue, the benefit only developer. And don’t argue with me that we would never complain about a car that benefitted only the driver because I will simply point out that I would complain if the AC only blew on the driver, or if the driver was the only one allowed to use the storage space or sit in a comfortable seat. Because for testers, there is no benefit to anonymous arrow functions. Period. I digress.

This got me thinking. For years, I have been hearing people argue that the testing pyramid is dead. And while these days most people would say that it simply needs to be adjusted for modern times, I think that’s a cop out. That’s like saying gaslighting simply needs to be adjusted for modern times.

No, the test pyramid is no longer relevant. The pyramid served its use during a time a when compute was expensive and time constrained. It said, limit your CPU-bound processing for the end of the SDLC, when you need it most, because it is a precious resource.

But if AI has taught us anything, it is that compute is no longer the precious resource it once was. Please don’t send me hate comments about this remark. I acknowledge that we currently are wasting water and energy on AI.

But my point is that what killed, well, mortally wounded, the test pyramid was Kubernetes. Kubernetes made it easy for us to architect systems to run all our tests as the gods intended, each in it’s own isolated container. It might be the only thing Kubernetes is good for. But, it no longer matters that our E2E test take 9 minutes to run because if we can run them all concurrently then our test runs take only as long as our longest test. Of course that doesn’t include the time it takes to mitigate flakes and resolve bugs, but that aside, it gives us a shot at being able to meet the DORA standard of 30 minutes for a test suite to complete.

So these days, it really doesn't matter what shape your test distribution is if you can execute everything concurrently. High test concurrency obsoletes all shapes.

So perhaps it’s time we stop obsessing over the geometry of our test strategies — be it pyramids, trophies, cones, or quadrants — and start focusing on the real constraints of modern software delivery: concurrency, observability, flakiness, and developer empathy. In a world where containers isolate, clusters scale, and CI/CD pipelines are fully parallel, test distribution shapes have become more about comfort than constraint.

Maybe the next diagram isn’t a shape at all . When the only thing that matters is whether the tests ran fast enough, failed usefully, and told us something we didn’t already know, the only shape that matters is flat.

(yes, I know flat is not a shape. It just sounded good. Thanks for noticing.)