How many e2e tests should I have?

Tens, not hundreds. The right size is enough to cover the critical user paths. Login. Primary workflow. Payment. Onboarding. Each path gets one or two tests. Beyond that the maintenance cost outpaces the value.

What library should I use?

Playwright is the dominant choice in 2026. The API is good. The reliability is best in class. The cross browser support is solid. Cypress remains credible. Older options like Selenium are usually not the right call for new projects.

How do I make e2e tests reliable?

Avoid sleeps. Use explicit waits for application state. Use stable selectors like data attributes, not CSS classes that change. Run tests against a real backend, not a fully mocked one. The flakiness usually traces to one of these.

What about e2e tests against production?

Synthetic monitoring runs e2e tests against production to verify the system works for real users. The tests should be read only or use a dedicated test account. The patterns are similar to staging e2e but with different operational concerns.

What is the worst e2e mistake?

Writing too many e2e tests because the team wants confidence. The maintenance overwhelms the team. The tests become flaky. The signal degrades. The right pattern is fewer, higher value tests with rigorous reliability discipline.

How do e2e tests fit in the test pyramid?

Many unit tests at the base. Some integration tests in the middle. A few e2e tests at the top. The pyramid shape reflects the cost and value of each layer. E2e is expensive per test. Unit is cheap per test. The right portfolio uses both.

How do I keep e2e tests fast?

Parallelize across browsers and shards. Run only against the changed surfaces in PR. Run the full suite on main. Cache the application build. The right setup runs the full suite in five to fifteen minutes.

Tech Debt and RefactoringMay 22, 202612 min read

End to End Tests: When They Help and When They Hurt

End to end tests exercise the application from the user's perspective. The test opens a browser, performs actions, and verifies the result. The tests are valuable because they catch integration failures unit tests miss. The tests are expensive because they are slow, flaky, and maintain heavy. The right balance is a small number of high value e2e tests guarding the critical paths, with unit and integration tests covering the rest.

Written by Yashveer Singh, founder of Yashveer Labs.

What you actually need to know

Tens of e2e tests, not hundreds.
Playwright is the modern default.
Stable selectors and explicit waits prevent flakiness.
E2e tests sit at the top of the test pyramid.
The right portfolio uses unit, integration, and e2e together.

Test type	Cost per test	Coverage
Unit	Cheap	Specific function
Integration	Moderate	Multiple units together
End to end	Expensive	Full user path
Synthetic production	Expensive	Production verification
Visual regression	Moderate	UI consistency
Contract	Moderate	API contracts

The core argument

End to end tests are the only tests that prove the system works for users. The unit test passes. The integration test passes. The browser opens, the user clicks, the page breaks anyway. The e2e test is what catches the failure that the other tests miss.

The cost of e2e tests is real. They are slow. They are flaky. They are maintain heavy. The team that writes hundreds of e2e tests pays the maintenance tax forever. The team that writes none ships breaking changes that the other tests did not catch.

The right balance is a small number of high value e2e tests. Critical user paths. Login. Primary workflow. Payment. Each gets one or two tests. The maintenance is manageable. The signal is strong. The team uses the time saved on unit and integration tests where the cost per test is lower.

The discipline that keeps e2e tests reliable is small. Stable selectors. Explicit waits. Real backends. Each is mechanical. The team that applies these has tests that pass reliably for years. The team that does not has tests that flake every release.

The synthetic monitoring layer is the same patterns applied to production. The e2e test runs against production to verify the system is working. The signal complements the alerts based on metrics. Both have a role.

The test pyramid in detail

Layer	Tests	Purpose
Unit	Hundreds to thousands	Specific function correctness
Integration	Tens to hundreds	Modules working together
End to end	Tens	Full user paths
Visual regression	Few key surfaces	UI consistency
Synthetic production	Few critical paths	Production verification
Manual exploratory	Pre release	Hard to automate cases

How much does this cost

Investment	Cost
Initial e2e setup with Playwright	One sprint
Each new e2e test	Hours to write, ongoing maintenance
CI infrastructure for e2e	Modest
Synthetic production monitoring	A few hundred USD per month
Maintenance per quarter	Real

Features the e2e suite must have

Stable selectors with data attributes.
Explicit waits, not sleep.
Real backends, not full mocks.
Parallelization in CI.
Screenshots and traces on failure.
A small focused suite.
A flake tracking process.
Synthetic monitoring against production.

Expert opinion

The teams that get the e2e balance right ship faster than the teams at either extreme. Too few e2e tests and the team ships breaking changes that the other tests did not catch. Too many e2e tests and the team drowns in maintenance. The right number is small. The right tests are the critical paths. The discipline is to write fewer better tests rather than more shallow ones.

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client SaaS had roughly four hundred e2e tests. The suite took forty minutes to run. The flake rate was high. The team had stopped trusting the suite. New tests were not being added because nobody wanted to maintain more.

We pruned the suite to thirty five tests covering the critical paths. We rewrote the remaining tests with stable selectors and explicit waits. We added parallelization and shard execution. The suite dropped to four minutes. The flake rate dropped to near zero. The team started trusting the suite again.

The other tests that had been e2e were rewritten as integration tests where appropriate. The total test coverage went up. The total maintenance cost went down. The shipping velocity improved measurably.

For more on the related work, see adding tests to a legacy codebase without going mad and CI cd pipelines that engineers trust a pattern library.

Common mistakes teams make

Hundreds of e2e tests. Maintenance overwhelms.
Few e2e tests. Breaking changes ship.
CSS class selectors. Flake on UI changes.
Sleeps instead of explicit waits.
Fully mocked backends. Integration failures not caught.
No parallelization. The suite is slow.
No synthetic monitoring against production.
Treating e2e as the answer when integration tests would have been cheaper.

A 30 day plan to right size the e2e suite

Week one. Audit the current suite. Identify the critical paths.
Week two. Prune the suite to the critical paths.
Week three. Rewrite for reliability. Stable selectors and explicit waits.
Week four. Parallelize. Add synthetic production monitoring.

For more on the related work, read adding tests to a legacy codebase without going mad and ci cd pipelines that engineers trust a pattern library. On the broader quality side, chaos engineering at startup scale is the natural next read.

FAQ

Frequently asked

Author

Why you should skip the agency and hire me instead

Agencies markup engineering work by three to five times. Yashveer Singh, founder of Yashveer Labs. I do the work directly. No project manager, no account manager, no overhead. The engineer you talk to is the engineer who writes the code. That changes the math on price, speed, and quality at the same time. If that sounds like the shape of project you have, we should talk.

Start the conversation See the work DM on Instagram