Frontend Testing

Requirement A frontend MUST use a logic test for pure logic, a browser specification for navigation and integration, and the route contract for every address.

Rationale Matching level to risk keeps the fast tests fast and reserves browser runs for behavior only a browser proves.

Requirement A test MUST prove a Case by calling its use case and asserting its Result, submitting a money-moving use case rather than only reading it.

Rationale Steps that call the use case and assert the Result let the model builder compute proof from the test body. A title tag claims proof without exercising anything. A money-moving use case that a test only reads never shows it can complete.

Example An evidence specification for placing an order submits the order and asserts the confirmation the success Result promises.

Requirement An evidence specification for a use case declaring a refusal MUST reach that refusal and assert it by its Result's code.

Rationale A refusal that only appears in a log never renders where a reader can see it. Addressing it by code also proves the code the Result declares is the code the page shows. The Case records the situation that reaches it.

Example The refusal alert carries the code, so the assertion names it.

Requirement A frontend test MUST assert observable behavior in each state applicable to what the test covers: loading, empty, error, forbidden, not-found, pending, validation, and success.

Rationale An assertion on internal state passes while the rendered page stays broken. The Case states which of these its situation reaches, so a logic test asserts no route state it cannot reach. The project records each state as a Term with labels per language.

Requirement A frontend test MUST NOT mock the generated contract types or an implementation-private function, nor a library its stack names.

Rationale A test may still replace the generated operation boundary, because that is an owned contract. Everything else it replaces becomes a claim about code the test no longer exercises.

Requirement A component or logic test that needs HTTP MUST serve its answers through network mocks generated from the published contract.

Rationale A mocked client proves the mock rather than the component. A network mock answers the same request the browser would send, so the generated client stays in the path it takes in production.

Example The workspace keeps one mock-generation command that regenerates them.

Requirement A browser test MUST create or identify its own data, its own authentication context, and its own expected state.

Rationale A test depending on execution order or on leftover data fails for reasons unrelated to the change under review. A test spends no seeded record; it creates the record it needs.

Requirement A frontend calling the API MUST hold a test asserting that its module tree resolves to the backend use-case folders and names no refused folder.

Rationale The mirror is the claim that makes a specification findable from a folder path. A check that runs on every build keeps it true when the backend adds or renames a use case.

Example The structure check resolves each folder name against the backend's Application tree.

Requirement Every public use case MUST sit in a Journey or name its background caller.

Rationale A public use case no Journey reaches and no background caller names has no stated path to it. The model builder reports each one, so the gap stays visible until a Journey or a caller claims it.

Requirement A browser suite MUST run through the command line, addressable per route and per file.

Rationale The command line is the interface every runner shares: the developer, the drill, and the integration job. A check that runs only inside an editor plugin or a proxy runner cannot be repeated by the next investigator.