Every layer of testing below end-to-end shares one assumption: that if each piece is correct, the assembled product will be correct. That assumption is wrong often enough to be the reason E2E testing exists.
What end-to-end testing is
End-to-end testing exercises a complete user journey through the real system — real browser, real network, real backend, real database — rather than testing a component in isolation. Nothing is mocked. If a third-party payment provider is in the path, the test goes through it.
That is the whole value proposition and the whole cost. E2E tests are the only tests that can tell you the product works, and they are the slowest, most fragile tests you will own.
Where it sits against unit and integration tests
- Unit tests verify one function in isolation. Milliseconds. Hundreds or thousands of them. They tell you which line is wrong.
- Integration tests verify that components agree — a service and its database, a client and its API. Seconds. Dozens. They tell you which seam is wrong.
- End-to-end tests verify a journey through everything. Minutes. A handful. They tell you the customer cannot check out, without telling you why.
The three are not substitutes. A unit test that passes while checkout is broken is not a failure of unit testing — it is unit testing doing precisely its job, at the wrong altitude for the question you are asking.
A full journey, run end to end
Here is a complete purchase — browse, add two products, apply a coupon, fill nine checkout fields, pay, and land on a confirmation — described in six lines and executed in a real cloud browser.
1. Open the store home page 2. Add the Ridgeline 2P Tent and the Titanium Pocket Stove 3. Open the cart, verify subtotal $351.00 and free shipping 4. Apply coupon NORTH20 and verify the discount is -$70.20 5. Check out with valid test data, card 4242 4242 4242 4242 6. Verify the confirmation shows an order number starting NW-
Passed. Order NW-854896, two items, $305.37 paid. Every layer was real: the cart maths, the coupon rule, the nine-field form with validation, the order creation. The replay shows the confirmation screen a customer would see.
What to cover
The single most common E2E mistake is trying to cover everything. E2E tests cost minutes each; a suite of four hundred is a suite nobody runs. Cover the journeys where breakage costs money or trust:
- Sign-up and sign-in. If these break, every other metric goes to zero.
- The primary conversion path, completed all the way to confirmation — not stopped at the payment step.
- Anything touching money. Pricing, discounts, tax, shipping, refunds. Assert on exact values.
- Journeys crossing a third party. Payment, auth, email. These break without any change on your side.
- Permission boundaries. One test proving user A cannot see user B’s data.
What to skip
- Field-level validation permutations. Unit-test the validator instead.
- Every empty state and every error copy variant.
- Admin and internal tooling, unless an outage there stops revenue.
- Anything a smoke test already covers. Do not pay E2E prices for a page-load check.
- Visual styling. That is a different tool and a different failure mode.
Why real devices change the answer
A resized desktop browser is not a phone. It has a different engine, different touch handling, different viewport behaviour, and different scroll physics. Plenty of layout failures appear only at real device widths.
Worth noting how that run was requested. The instruction was simply “run this test on a mobile device viewport, 390 pixels wide by 844 tall, like an iPhone”, stated in the same plain English as the rest of the test. No device configuration, no capability matrix.
The flakiness problem, honestly
E2E tests have a deserved reputation for failing when nothing is wrong. Every layer they touch can introduce timing variability, and a test that clicks a button then immediately asserts on a counter is racing the application.
1. Open the store home page 2. Click Add on the Ridgeline 2P Tent 3. Immediately verify the cart badge shows 1, without waiting or retrying
“The cart badge read immediately after clicking Add returned 0, not 1. The cart state updated later, confirming the badge delay.” A genuine race — and note the report distinguishes a timing defect from a functional one, which is the distinction that decides whether you fix the app or the test.
Treat a flaky test as a broken test. One randomly failing test teaches the whole team to ignore red builds, which costs you every other test in the suite. Fix it or delete it; leaving it is the only option that is strictly worse than both.
What E2E testing actually costs
The honest accounting has three lines, and only one of them is the one teams budget for.
- Writing the test. The part everyone estimates. Historically an hour or two per journey, including selectors and waits.
- Running the test. Minutes of CI time, multiplied by every PR, forever. Real, but usually the smallest line.
- Maintaining the test. The line that kills suites. Every redesign, every class rename, every new modal breaks tests that found no bugs, and someone has to work out which failures are real.
Nobody abandons E2E testing because writing the tests was too hard. They abandon it because maintaining them stopped being worth it.
Which is why the interesting change is not in execution speed but in what the test is written against. A test that says .cart-summary .total is a maintenance liability with a shelf life. A test that says “verify the order total is $305.37” describes the product, and survives every refactor that does not change the product.
Every run on this page was written that way — as sentences, not selectors — and each took about two minutes from description to verdict, including the agent writing its own Playwright candidate.
Frequently asked questions
What is end-to-end software testing?
End-to-end testing exercises a complete user journey through the real system — real browser, real network, real backend, real database — rather than testing a component in isolation. It is the only kind of test that verifies the pieces work when assembled.
What is the difference between E2E and integration testing?
Integration testing checks that two or more components talk to each other correctly, usually without a browser and often with parts mocked. E2E testing drives the entire assembled system the way a person would, with nothing mocked. Integration answers "do these two agree"; E2E answers "does the product work".
How many end-to-end tests should you have?
Far fewer than unit tests. The usual guidance is a handful of critical journeys — sign-up, sign-in, the primary conversion path, anything touching money. Ten to thirty well-chosen E2E tests protect more revenue than three hundred poorly chosen ones.
Why are E2E tests considered slow and flaky?
Because they exercise every layer, so every layer can introduce timing variability — network latency, animation, async rendering, third-party scripts. Traditional E2E tests also assert on DOM structure, which changes for reasons unrelated to behaviour, producing failures that are not bugs.
Should E2E tests run on every pull request?
A core subset should — the journeys where breakage costs money. The full suite usually runs nightly. The deciding factor is duration: anything that keeps a developer waiting more than about ten minutes will eventually be moved out of the PR gate and then ignored.
Do E2E tests replace unit tests?
No. They answer different questions and fail differently. A unit test tells you which function is wrong; an E2E test tells you the customer cannot check out. You want both, in very different quantities.