Suggest an editImprove this articleRefine the answer for “Why shouldn't there be many E2E tests?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**E2E tests** should not be numerous because they are the most expensive, slowest and most fragile of all test types. **Key point:** E2E tests should cover only the key user scenarios, while the rest of the checking is more cost-effective to cover with unit and integration tests, which are faster, more stable and cheaper.Shown above the full answer for quick recall.Answer (EN)ImageBecause E2E tests are the most expensive, slowest and most fragile of all test types. ## Reasons 1. **Slow runs** Each test launches a browser, navigates through pages, waits for rendering, and performs real actions. A single test can take seconds or tens of seconds, which is dozens of times slower than unit tests. 2. **High maintenance cost** The smallest changes in the interface, text, markup or network scenarios can break a test. The more of them there are, the more time goes into fixing them. 3. **Dependency on the environment** E2E tests depend on the network, the database, the API, the infrastructure. Any instability makes them flaky. Mass E2E = mass false failures. 4. **Overlap the same scenarios** E2E tests often check similar user flows. If there are too many of them, duplication appears that adds no extra value and only slows the process down. 5. **Kill the team's speed** Long runs → a long feedback loop → slow decision-making → slower development. **The essence:** E2E tests should cover only the key user scenarios. The rest of the checking (logic, integrations, states) is more cost-effective to cover with unit and integration tests, because they are faster, more stable and cheaper.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.