A team's end-to-end suite takes ninety minutes and fails intermittently. How many end-to-end tests should there be?

The economics

End-to-end tests are the most expensive to write, the slowest to run, the most likely to be flaky, and the most valuable when they catch something — because they are the only tests that exercise the composition.

That combination means the correct number is small and chosen deliberately, not whatever accumulated.

How to choose them

• One per critical journey, where a critical journey is one whose failure is unacceptable: sign up, subscribe, pay, cancel, invoice. Five to fifteen for most products.
• Chosen by business consequence, not by feature count. A journey used by every customer daily deserves one; a rarely-used administrative flow does not.
• Each testing the happy path plus the one failure mode that matters, rather than exhaustive variation — variation belongs at lower levels where it is cheap.

What to do with the rest

Push them down. Most end-to-end tests exist because the logic they exercise is not testable at a lower level — which is a design problem rather than a testing one. Pushing logic into units that can be tested without I/O is the structural fix, and it improves the code as well as the suite.

Integration tests at service boundaries cover the interactions; contract tests cover compatibility; unit tests cover logic.

The suite's own requirements

• Under ten minutes, or it is not run before merge and its feedback arrives too late to be actionable.
• Deterministic, with a hard flake policy — a flaky end-to-end suite is worse than none, because it trains the team to re-run and therefore to ignore real failures.
• Parallelised, and running against an ephemeral environment so tests do not contend.
• Diagnosable on failure: a failure that requires an hour of investigation to attribute is a failure that will be re-run instead.

The review to run annually

Which end-to-end tests have ever caught a real regression? The ones that never have are costing time and flakiness for no return, and deleting them improves the suite. That question is answerable from the failure history and is almost never asked.