> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/testing-reading-maintaining/test-pyramids.md). # Test Pyramids ## Classic Testing pyramid * More resource expensive and time consuming tests at the top (few of them). Cover less, but make sure everything fits and works together. * More unit tests, less expensive, mocked/stubbed, fast running tests at the bottom. Cover more of the code base. * * * ### issues * Overuse of E2E tests, often reaching the Inverted Test Pyramid * No consensus on the definition of Integration Tests, and over-reliance on large scoped integration tests makes it hard to maintain * No consensus on the definition of Unit Tests, and writing unit tests that are structurally coupled to code with over-mocking, thus fragile when refactoring * The Test Pyramid does not include Acceptance Tests needed for testing Acceptance Criteria, but instead it relies on fragile E2E Tests for that * The Test Pyramid doesn’t provide us guidance for testing microservices, specifically it doesn’t even mention Component Tests & Contract Tests which are crucial for microservice testing * * ## Testing Hourglass * As software projects grow, often the shape of our test pyramid distribution becomes undesirable, either top heavy (no unit or medium integration tests), or like an hourglass. * The hourglass test distribution has a large set of unit tests, a large set of end-to-end tests, and few or no medium integration tests. * To transform the hourglass back into a pyramid — so that you can test the integration of components in a reliable, sustainable way — you need to figure out how to architect the system under test and test infrastructure and make system testability improvements and test-code improvements. * ## Trophy Pyramid ![testing-trophy.png](/files/-M-xmSMdRIs4U8o-FUBC) * ROI is better to have more integration tests, than unit tests. * Int tests cost more and slower than unit tests. But need to write more unit tests, to match one Int test * Rely on static typing and compiler to handle syntax and language errors * use of static analysis tools * Dont test business logic * Unit tests * to test edge cases * Integration tests * to handle business flows or integration points ie database, http calls * test multiple areas at once * make sure that parts of system work together * Less mocking, more real objects used * End to End test * Bring up whole app, test user flows * critical paths * little to no mocking, some for services dont want to use * Integration and end to end can be very fuzzy demarcation * Reduce duplication of tests, if unit is tested via Integration or end to end test, it does not need to be retested * Makes code more brittle, more places to change code * If test does something that your consumer of that code doesnt then it's testing implementation details * If refactor breaks your tests, then it's testing implementation details * * * * * ## Testing Quadrant * * ## New testing pyramid ![new-test-pyramid.png](/files/PaIHeypJlWc9OO3P8k16) * ## Links * *