Test cases

Test cases record what a planned surface has to actually do. They live beside the thing they describe rather than in a separate document, so the acceptance criteria and the design that claims them never drift apart.

Where you write them

Every writing panel in the Structure inspector ends in Test cases — for the selected route, component, or store — and each endpoint's contract in Backend carries the same panel under its request and response tables.

Cases are stored with their subject: a route's on the route, a component's or store's on that shared definition, an endpoint's on the endpoint. A component used on six routes has one set of cases, because it is one component.

What a case says

Each case has four parts:

• Title — the behaviour, written as a sentence: "shows an empty state when the traveller has no trips".
• Proven by — unit, integration, or end-to-end. This decides who runs the test and what it is allowed to assume.
• Steps — the setup and the action, one per line, in the application's own vocabulary.
• Expected — what must be true once the steps have run.

Cases collapse to their titles, so the list reads as a contract. Expand one to write or review its detail.

Generate

Generate writes cases from what the project already knows about the selected subject — a route's parameters, guards, and attachments; a component's props, slots, and render guard; a store's state and actions; an endpoint's parameters and declared responses — together with the project description, roles, and features from Domain. That grounding is what separates a case that could only be about this surface from one that would read the same in any application.

Generation is add-only and matched on the behaviour: pressing it twice adds nothing, a case you reworded is never overwritten, and anything you wrote by hand is left exactly as written. Each press covers one subject, so you spend on the parts of the plan you actually ask about.

In the export

Every subject with at least one case written on it gets a test suite in the generated project, beside the file it is about — a page and its suite, a component and its suite, a route handler and its suite. Each case becomes a pending test carrying its steps and expectation, so an unimplemented criterion is reported as outstanding work rather than as a test that passes without checking anything. The generated project declares its test runner and a test script, so the suites run from the first download.

Empty rows are never counted or exported. The Scaffolding panel's header shows how many cases the project actually holds.

In the report

The project report's Test coverage section lists the criteria grouped by the surface each was written beside — the route, component, store, or endpoint — with its steps and expectation. A feature the traceability matrix links to a route you wrote criteria on counts as covered there, rather than reading as untested. The same section appears in a shared report, so a reader who has the link sees what the design says it must do without opening the workspace.

Nothing in it is a result. The report states what has to be true, never that it is.