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

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 costly to maintain. 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

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

A 30 day plan to right size the e2e suite

1. Week one. Audit the current suite. Identify the critical paths.
2. Week two. Prune the suite to the critical paths.
3. Week three. Rewrite for reliability. Stable selectors and explicit waits.
4. 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

• How many e2e tests should I have?
• What library should I use?
• How do I make e2e tests reliable?
• What about e2e tests against production?
• What is the worst e2e mistake?
• How do e2e tests fit in the test pyramid?
• How do I keep e2e tests fast?

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