The testing pyramid should look more like a crab
By moving the &#x27;meat&#x27; of the tests up high into the hierarchy, the author has just re-invented the testing ice cream cone with a different flavor.<p>In software, we can make pretty much any process work for 18 months, before it starts to fall apart. If you don&#x27;t stay at a company for at least a couple of years after they start doing testing in earnest, you won&#x27;t really see that what you&#x27;re doing doesn&#x27;t scale&#x2F;isn&#x27;t resilient to changing requirements.<p>I have watched so many people try to rescue deeply coupled integration or E2E tests and it&#x27;s just painful to watch. It&#x27;s a deadly cocktail of cargo culting and Sunk Cost Fallacy - we don&#x27;t know for sure all the corner cases these tests cover, so we aren&#x27;t going to delete them and lack the confidence to rewrite, so we&#x27;ll spend all day trying to fix them, and if that doesn&#x27;t work, we&#x27;ll pair with someone for day 2 to get it fixed. That&#x27;s 3 man days, for a handful of tests. I&#x27;ve seen it many times, on different teams, rarely are there enough other people noticing how crazy this is to stage an intervention. It&#x27;s crazy.<p>A contributory reason to why fixing such tests takes so long is that they&#x27;re so slow. Slow tasks have poor feedback loops. Testing, at least when done as part of CI&#x2F;CD, is meant to provide <i>fast</i> feedback, and E2E tests fail at this (most especially at 18 months and beyond, where your E2E test is one of hundreds).<p>There&#x27;s a physics and a psychology to the tiers in the testing pyramid that I meant to write up publicly but I don&#x27;t think ever escaped a corporate wiki. Here are the Cliff&#x27;s Notes, based on my own metrics but corroborated by the handful of people who&#x27;ve inspired my testing journey:<p>1) Moving tests down a tier reduces the power of the test, so you need more of them (about 5x)<p>2) Moving tests down a tier makes them much faster. (8x common, 10x best case, depending on framework)<p>3) The simplest tier of tests will be rewritten or deleted when requirements change. All other tests will be &#x27;rescued&#x27;, sometimes at great expense in time and energy.<p>Rules 1 &amp; 2 create a pseudo-rule, the 5&#x2F;8ths Rule. If you move a functional test to units, the same coverage will run about 30% faster in aggregate, <i>and you will not have to provide ongoing support for those tests</i>. That&#x27;s a huge win. If you pull a test down 2 levels, they&#x27;ll run 60-75% faster.