Flows are not tests, and that is the point

When we describe flows — recording a path through your product that has to keep working — the first response is usually: so, end-to-end tests?

No. And the difference is worth being precise about, because building one when you wanted the other wastes a lot of time.

What a test does

A test asserts. It encodes a claim about correct behaviour, runs on demand, and fails loudly when the claim stops holding. It is written by someone who already knows what correct means, and its value is that it keeps knowing after they have forgotten.

Tests are excellent. Flows do not replace them and we would not suggest otherwise.

What a flow does

A flow records. You walk a path — sign up, add to basket, check out — and it captures what happened: the steps, the network activity, the console, what the page looked like at each point.

It makes no assertion. It has no opinion about correctness. It is a record of what this path looked like on a day it worked.

Why that is useful

Because the expensive part of most bugs is not fixing them. It is reproducing them.

A bug report says "checkout is broken". The person who wrote it could not see the console error or the request that returned 500, so those are not in the report — not from carelessness, but because that information was never available to them. Whoever picks it up spends an hour recovering context that existed and was thrown away.

A flow is that context, captured while it was still there.

The second use, which is the real one

When something nearby changes — by you, by a contractor, by an agent — the flow is what you replay. Not to assert correctness, but to see what is different.

This is where it earns its keep on work you did not do yourself. When someone else touches your checkout, "does it still look like it did" is a question you can answer in thirty seconds with a recording and cannot answer at all from a diff.

Why not just write the test

Often you should. If you know what correct means and you can express it, a test is strictly better: it runs unattended and fails on its own.

Flows cover the case where you cannot cheaply write that down. Nobody has an assertion for "the checkout page still feels right", and the paths that break in production are frequently the ones nobody wrote a test for — because if they had thought of it, they would have.

The honest framing: a flow is what you record when you know something matters but not yet what to assert about it. Sometimes the flow later tells you what the assertion should have been. That is a good outcome, and then you should write the test.