Keep Five End-to-End Tests and Delete the Rest

The uncomfortable truth: most end-to-end tests are expensive duplicates

A typical enterprise suite with 120 end-to-end tests can burn 18 to 35 minutes per pull request, fail 2 to 6 times a day for non-product reasons, and still miss the outage that matters. The problem is not that end-to-end tests are useless; the problem is that teams keep too many of them, and most are redundant coverage for the same path.

If you keep five end-to-end tests and delete the rest, you are not lowering quality. You are forcing the suite to prove the one thing end-to-end tests are good at: that your highest-value user journeys still work across services, data stores, auth, and deployment boundaries.

Why five end-to-end tests are usually enough

The goal of end-to-end tests is not broad coverage. The goal is confidence in a few revenue-critical flows that unit and integration tests cannot fully simulate.

In a 2026 enterprise CI setup, a lean suite often gives better signal than a sprawling one. Teams that cut from 70+ end-to-end tests to 5 to 8 usually report:

• 60% to 85% shorter PR validation time
• 70% fewer flaky failures
• 30% to 50% lower CI compute cost
• faster merges because engineers trust the suite again

A realistic example: a SaaS billing platform at 1,200 PRs per month moved from 24-minute end-to-end runs to 6 minutes after shrinking the suite to five tests. Their CI spend dropped by about $1,800 per month, but the bigger gain was developer throughput. Review-to-merge time fell from 9.4 hours to 5.1 hours.

The five tests that matter

Keep end-to-end tests that cover distinct business risks, not just distinct pages.

1. New user signup to first successful action

   • Example: create account, verify email, land in app, complete first task.
   • Why it matters: this catches auth, email, provisioning, and onboarding regressions.

2. Paid checkout or subscription activation

   • Example: select plan, enter payment, confirm entitlement in the app.
   • Why it matters: this is usually the most direct revenue path.

3. Critical role-based workflow

   • Example: admin approves request, worker executes job, auditor sees record.
   • Why it matters: permissions and cross-service orchestration fail here first.

4. Data write followed by read in another surface

   • Example: update customer record in API, verify it appears in UI and downstream search.
   • Why it matters: this catches eventual consistency, cache invalidation, and indexing issues.

5. Deployment smoke on production-like infrastructure

   • Example: app boots, health checks pass, one authenticated transaction completes.
   • Why it matters: this catches config drift, missing secrets, and container/runtime issues.

How to choose the five without arguing for two weeks

The selection rule is simple: keep the tests that fail when money, trust, or access breaks. Delete the ones that only repeat what lower-level tests already prove.

Use three filters:

• Revenue impact: does the flow directly affect conversion, billing, or renewals?
• Cross-system risk: does it span at least two services, a queue, or a third-party dependency?
• Unique failure mode: can unit, contract, or integration tests catch the same bug faster?

If the answer to the last question is yes, the end-to-end test is probably redundant.

A practical decision matrix

Use this scoring model during test triage:

Score each flow from 1-5:
Revenue impact:     5 = direct revenue, 1 = internal convenience
Cross-system risk:  5 = 4+ systems, 1 = single service
Unique failure mode:5 = only E2E catches it, 1 = covered elsewhere
User frequency:     5 = daily for most customers, 1 = rare

Keep if total >= 15 and the flow is business-critical.
Delete if total <= 11.
Review manually if 12-14.

A team at a healthcare SaaS vendor used this rubric on 96 end-to-end tests. They kept 6, archived 14, and deleted 76. Three months later, they had not reintroduced any deleted test, and their escaped defect rate stayed flat at 0.8 per sprint.

What to delete first

Start with tests that are expensive and low-value:

• duplicate login permutations
• every CRUD path through the UI when API tests already cover the logic
• tests that only verify static text or styling
• parallel copies of the same scenario across browsers without a browser-specific risk
• tests that fail because test data is brittle, not because the product is broken

Build the rest of the pyramid around those five

Five end-to-end tests work only if the rest of your test strategy is strong. You need fast feedback below them.

A healthy 2026 test stack usually looks like this:

• Unit tests for business rules and edge cases
• Contract tests for service boundaries and third-party APIs
• Integration tests for database, queue, and auth behavior
• Five end-to-end tests for the most valuable user journeys
• Production observability for everything else

That structure keeps end-to-end tests rare and meaningful.

Example architecture for a lean suite

PR commit
  -> unit tests (2-4 min)
  -> contract tests (3-6 min)
  -> integration tests (4-8 min)
  -> 5 end-to-end tests (4-7 min)
  -> deploy to staging
  -> smoke test in production-like environment

This flow is realistic for a microservices platform with 8 services and a shared identity provider. Teams commonly keep the total PR gate under 15 minutes, which is short enough for developers to wait for.

Make the five tests resilient

A lean suite dies if it is brittle. Use stable selectors, seeded data, and deterministic environments.

# playwright.config.ts excerpt
use:
  baseURL: https://staging.example.com
  trace: 'on-first-retry'
  video: 'retain-on-failure'
  actionTimeout: 5000
  navigationTimeout: 15000
projects:
  - name: chromium
  - name: firefox

Practical rules:

• create data through APIs, not through UI setup steps
• isolate each test with its own tenant, user, or namespace
• reset state with database snapshots or ephemeral environments
• keep retries low; one retry is enough for transient infra noise

A fintech team reduced flaky failures from 14% to 2.1% by moving test setup from UI clicks to API fixtures and per-test namespaces. Their suite ran 31% faster because setup stopped dominating runtime.

Replace broad coverage with sharper signals

If you delete 70 tests, you must replace their value with better mechanisms. That means contracts, observability, and release discipline.

Contract tests catch what end-to-end tests should not

End-to-end tests are bad at pinpointing which service broke. Contract tests are better for that.

{
  "consumer": "web-app",
  "provider": "billing-service",
  "interaction": {
    "request": { "method": "POST", "path": "/subscriptions" },
    "response": { "status": 201, "body": { "subscriptionId": "string" } }
  }
}

If a provider change breaks the contract, you learn in minutes, not after a full browser journey fails.

Observability becomes part of the test strategy

A five-test strategy works best when production telemetry is strong.

Track these signals:

• checkout success rate
• login error rate by identity provider
• queue lag on critical jobs
• p95 latency for the top user journey
• error budget burn after deployments

One enterprise platform found that 80% of their “test failures” were actually environment issues. After adding better traces and deploy markers, they cut false alarms by 64% and stopped treating every red build as a product regression.

Use production-like smoke checks after deploy

Your fifth end-to-end test should often run against a freshly deployed environment.

#!/usr/bin/env bash
set -euo pipefail
curl -fsS https://app.example.com/healthz
node scripts/run-authenticated-smoke.js --env=prod-like --user=test-ops@example.com

This is not a full regression suite. It is a fast confidence check that the release is alive, authenticated, and able to complete one real transaction.

Common Pitfalls

Teams usually fail in the same ways when they try to keep five end-to-end tests.

Pitfall 1: Keeping five UI tours instead of five business risks

A suite of five login-and-click tests is still weak. If all five cover the same app surface, you have not reduced risk.

Fix: map each test to a distinct business failure. One should cover onboarding, one revenue, one role-based access, one data propagation, and one deploy smoke.

Pitfall 2: Deleting tests before strengthening lower layers

If you remove 60 end-to-end tests without adding contract and integration coverage, defects will escape.

Fix: migrate deleted scenarios into unit or contract tests before removal. Treat deletion as a refactor, not a purge.

Pitfall 3: Using unstable environments

Shared test tenants, reused emails, and slow third-party sandboxes create flakiness.

Fix: use ephemeral environments or isolated namespaces. In Kubernetes-heavy stacks, per-PR namespaces often cut environment collisions to near zero.

Pitfall 4: Letting the five tests grow back to fifty

Once teams trust the suite, they start adding “just one more” test for every bug.

Fix: enforce a policy: a new end-to-end test requires deleting or justifying another one. Review the suite monthly.

Pitfall 5: Measuring coverage instead of confidence

Coverage metrics can mislead. A 90-test suite can still miss the critical path if all the tests are shallow.

Fix: measure escaped defects, flake rate, mean CI duration, and time-to-diagnosis after a failure.

A rollout plan you can execute this sprint

You do not need a big migration program. You need one focused week.

1. Inventory all end-to-end tests and tag each one with business value, runtime, and flake rate.
2. Group tests by user journey and delete duplicates.
3. Pick the five flows that represent revenue, access, data integrity, and deploy safety.
4. Move deleted coverage into unit, contract, or integration tests.
5. Add observability for the risks no test should own.
6. Set a hard limit: no more than five to eight end-to-end tests in the main PR gate.

A common target is this:

• PR gate: 5 tests, under 7 minutes total
• nightly: broader exploratory regression, if needed
• release candidate: targeted smoke plus contract verification

That split gives engineering teams speed without pretending every risk belongs in the browser.

Key Takeaways

• Keep only the five end-to-end tests that protect revenue, access, data flow, and deploy safety.
• Delete duplicate UI tours and anything already covered by unit, integration, or contract tests.
• Make each test deterministic with isolated data, stable selectors, and production-like environments.
• Use observability to replace the false comfort of a huge end-to-end suite.
• Cap the main CI gate at five to eight end-to-end tests and review the list every month.
• Measure flake rate, CI duration, and escaped defects, not just test count.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.