Your CI run is green. All 340 tests passed. Your team ships the release. Twenty minutes later, a customer emails to say they can't check out.
You look at the test suite. The cart tests passed. The payment form tests passed. The order confirmation test passed. Every individual piece of the checkout journey has a green checkmark next to it.
And yet checkout is broken.
This is not a hypothetical. It is the natural outcome of optimizing for test count instead of user journey coverage — and it happens to teams with good intentions, experienced engineers, and high coverage numbers every day.
Why Isolated Tests Can't Tell You If Your Product Works
An isolated test suite is one where individual tests each cover a slice of behavior: a button renders, a form validates, a page loads. Each test is technically correct. Run in isolation, each passes consistently.
The problem is that real users do not interact with slices. They complete user journeys — sequences that span multiple pages, state changes, and API calls. They navigate from a product page to a cart, from a cart to checkout, from checkout to a payment form, from a payment form to a confirmation screen. The behavior that matters is the sequence, not the individual steps. And that sequence is exactly what isolated tests never exercise.
Consider what happens when an API response changes the shape of cart data between the cart render step and the checkout step. Your cart test passes — it does not read the checkout step. Your checkout test passes — it mocks the cart data in setup. The integration between them is broken, and no test in your suite is watching it.
Fragmentation does not just miss integration bugs. It actively creates blind spots for the bugs that matter most.
Five Things Flows Do That Isolated Tests Cannot
The alternative to testing slices is testing complete user journeys. We call these flows — a single automated Playwright script that runs one user journey from entry to measurable outcome, with real browser interactions, real API calls, and real session state throughout. No mocking between steps.
1. A passing flow proves the feature works
When a flow navigates from product page to order confirmation using real browser interactions, real API calls, and a real session — without any mocking of intermediate steps — its result is definitive. If it passes, checkout works right now, in the environment where it ran.
No fragmented test suite can make that statement. A collection of green slices is evidence that the slices worked. It is not evidence that the feature works. The distinction is not subtle. It is the entire point of having tests.
2. Flows give you precise, actionable failures
When a flow fails, you know exactly where in the user journey it broke. The step name, the screenshot at the point of failure, the trace showing every network call and DOM state — all of it points to a single location in a single journey.
When fragmented tests fail, they produce a different problem: too much signal. A UI change that shifts a button's position in the checkout layout can break the cart render test, the cart total test, the address form test, the shipping selector test, and the payment test — simultaneously, for the same root cause. Developers spend their morning triaging five test failures that share one fix.
A flow fails once, in the right place, for the right reason.
3. Flows are dramatically cheaper to maintain
Maintenance cost scales with the number of tests touching a given piece of the UI. A checkout flow with twelve fragmented tests requires twelve updates when the checkout layout changes. Selectors, assertions, setup scripts — all duplicated, all brittle, all demanding attention for the same root cause.
One flow covering the same surface requires one update. Selector changes live in a single page object. The behavior assertion lives at the end of the journey, where it belongs. The maintenance surface is a fraction of what fragmentation produces.
For teams with hundreds of fragmented tests, the hidden cost is not the CI minutes — it is the ongoing engineer time spent keeping the suite from rotting. Flows eliminate most of that overhead by design.
4. Flows catch real integration bugs
The most damaging production bugs are not "the button doesn't render" bugs. They are state propagation failures, session edge cases, API contract mismatches between consecutive steps, and race conditions that only appear in realistic navigation sequences.
Fragmented tests miss all of these by construction — they each test a single slice with the rest of the world mocked out. A flow catches them because it runs the real journey. The session is real. The API calls are real. The state transitions between steps are real. Integration bugs have nowhere to hide.
5. Flows speak the same language as your product
A flow named guest-checkout-flow.spec.ts is immediately legible to everyone involved in shipping software — engineers, product managers, QA leads, and engineering leadership. Its result maps directly to a product question anyone can ask: "Does guest checkout work?"
A suite of 340 fragmented tests does not answer that question. It answers 340 narrower questions that nobody outside of QA has context to interpret. Coverage conversations become QA-only discussions instead of product conversations.
Flow-based coverage is business-legible by default. When an engineering lead needs to know what's tested before a release, the answer is a list of flows — not a test runner output that requires decoding.
The Compounding Problem
Isolated test suites do not stay manageable. They grow. Every sprint adds more slices. The coverage gaps widen because new isolated checks get added next to the old ones rather than filling in the missing end-to-end paths. By the time a team recognizes the problem, they are sitting on 500 tests with no clear picture of which user journeys — which flows — are actually verified.
The failure mode is gradual but predictable: CI run times inflate, flakiness accumulates, developers start treating red as noise, and the suite that was supposed to catch regressions before production has trained the team to merge anyway.
Flows do not have this trajectory. A suite of 50 focused flows covering 50 real user journeys stays at 50 meaningful tests. It does not drift into entropy because there is no natural pressure to add fragments. Either a journey is covered end-to-end, or it is not.
What to Do With an Existing Isolated Suite
Rewriting hundreds of tests is not a realistic starting point. The practical approach is to start at the critical path.
Identify the three or four user journeys — the flows — that would generate a customer complaint within an hour of breaking. For most products, that list is short: login, checkout, the core action that creates business value, and password recovery. Write a single flow for each. Run them on every commit. Watch what they catch that the existing suite misses.
After the first wave, audit which fragmented tests cover the same journeys as your new flows. Most of those fragments can be deleted — they are now redundant and weaker. You have not lost coverage. You have improved it while shrinking the maintenance surface.
Expand from there by adding flows for the next tier of critical journeys. The fragmented tests that have no corresponding flow can be evaluated individually: do they cover something the flow misses, or are they checking rendering details that have no bearing on whether the feature works? Most of them are the latter.
The Standard Worth Holding
The purpose of a test suite is not to produce a large number of passing checks. It is to give your team confidence that the product works before it reaches users.
Fragmented tests can pass comprehensively while that confidence is completely unjustified — as the customer who cannot check out will tell you. Flows tie the test result directly to the outcome that matters. If the flow passes, the journey works. If it fails, something real is broken and you know exactly where.
That is the only standard worth building a test suite around.
Originally published on the QA Guardian blog.
