The "Test Pyramid" is a metaphor that tells us to group software tests into buckets of different granularity. It also gives an idea of how many tests we should have in each of these groups. [^mf1] While the naming of each layer in the pyramid varies between different types of software application/architecture, the 2 general principles (supposedly independent of system application) are: - Write tests of different level of granularity/scope - The more high-level you get, the fewer tests of that type you should have The original idea was conceived by Mike Cohn in his book "Succeeding with Agile".  ## Limitations of the Testing pyramid metaphor In [[Microservices MOC]] and [[Serverless MOC|Serverless]] architectures in particular, components of the system (microservices) are by nature small and the risk profile of such systems changes to being less about the implementation detail of each component and more about the interaction between such systems. Because of this, the [[Testing honeycomb]] is seen by many as a better approach, with integration tests accounting for the bulk of the test suite. --- ## References - [The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html) by [[@Martin Fowler]] & [[Ham Vocke]] - [Testing Pyramids & Ice-Cream Cones](https://alisterbscott.com/kb/testing-pyramids/) - Visual representations of different types of pyramids, including... - Software Testing Ice-Cream Cone