Flows

A flow is a short list of plain steps that says what a journey through your app should do. It lives in your repo, rides the PR that changes it, and Tada replays it on every preview deploy.

There is no test suite, no selectors to maintain, and no framework to learn. If you can describe the journey to a colleague, you can write the flow.

Where flows live

Flows are markdown files under .tada/flows/ in the repo they test:

.tada/
  flows/
    checkout.md
    login.md

Tada reads them at the deploy SHA, the exact commit the preview was built from. That is what makes a flow honest: change a feature and its flow in the same commit, and the run that gates the PR uses the new flow, not last week’s.

What a flow looks like

---
name: Checkout with a promo code
enabled: true
---

Whatever context you want. This part is for humans and Tada ignores it.

- goto /checkout
- click Pay
  expect: Order confirmed

Front matter carries the name shown on the run, and enabled so you can park a flow without deleting it. Everything after it is prose for whoever reads the file next. The steps are the list at the end.

Steps and expectations

A step is an action. An expect: under a step is a check.

goto /path	open a path on the deployed build
click Pay	click the thing labelled Pay
fill Email with …	type into a named field
scroll down	move down the page
expect: Order confirmed	that text must be on screen after the step above

An expect: is text a person can see on the screen, not a CSS selector, not a description of the page. expect: Order confirmed passes when those words render. expect: the page looks right never passes, because nothing on screen says that.

That distinction is the one thing worth getting right the first time. A flow with no expect: on its payoff proves the app did not crash and nothing more.

What Tada does with them

On every preview deploy, Tada replays the whole set, not just the flows touched by the PR. A change to checkout can break login, and the only way to know is to run login too.

Each flow returns a verdict, and the run’s verdict is the worst of them:

• Passed. Every expect: held. The demo is published and posted to the PR.
• Blocked. A step failed on the real build. The check goes red, the merge stops, and you get the frame where it broke plus the few before it. No demo goes out.
• Errored. Tada itself failed. Nothing was proven about your code, so the check is neutral and never red.

Getting past a login

Most journeys start behind a sign-in. Each repo gets a throwaway test account that your seed creates in every environment, and Tada signs in with it, so a flow can start at the real front door rather than skipping it.

See Getting started to set one up.