Member-only story
The Test pyramid: A flawed approach to Testing in Modern Software Development
The Test Pyramid concept has a history that spans over a decade. It has evolved and adapted to various software development practices and may vary based on the context and evolving technologies. While this concept has been praised for promoting a structured approach to testing, it’s not without its flaws and limitations that make it less than ideal for all scenarios.
A little introduction about the Test Pyramid
The test pyramid is a concept developed by Mike Cohn in “Succeeding with Agile” (2009).
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.
We’re classifying our tests depending on the degree of isolation of elements to be tested.
Its essential point is that you should have many more low-level unit tests than high level end-to-end tests running through a GUI, because the lower tests are cheaper to implement and fast to execute.
A misconception about the previous picture is that the UI can only be tested in the last level. There are tools like Jest that allows to test UI from lower levels. And what are exactly service tests? Hard to grasp.
Over the years, many individuals, including myself, have reimagined the testing pyramid proposed by Mike Cohn:
- The community has adopted the name E2E instead UI. It better reflects the purpose of tests at this level, which focus on testing the entire application or system from the user’s or external system perspective rather than just the user interface.
- The community has adopted the name Integration instead Service.
- Alister Scott added the Manual session based testing at the top.
- Noah Sussman] reimagined the test pyramid as a bug filter.
- Martin Fowler has contributed to expand the test pyramid in his own writings and presentations, splitting…
