Testing Pyramid

The pyramid is a visual metaphor: the largest level (at the bottom) is unit tests, which are fast and the most numerous. The middle layer is integration tests, fewer in number. The top is UI/end-to-end tests, the least numerous. As you go up, tests become more expensive in time, effort, and fragility, so you want proportionally fewer of them.

By following the pyramid, most bugs are caught at the cheapest level. If the pyramid is inverted (lots of end-to-end tests, few unit tests), the test suite tends to be slow and fragile.

• Unit testing is where you start. Unit tests are run as separate functions and execute quickly. That means you can afford to write lots of unit tests.
• After the unit tests, there must be an integration test layer. These verify the integration of modules. You will require fewer integration tests than unit tests.
• End-to-end tests at the top simulate real-world user scenarios. They are essential but slow and expensive to maintain.
• Organizing tests this way, you receive quick feedback (most tests are quick unit tests), and when your UI test fails, there's a better chance it's due to a real problem.