Blazor Testing

Requirement A client solution MUST contain Domain, Application, Web, and end-to-end test projects and no other baseline test project.

Rationale This replaces the backend testing project set, because there is no API factory, PostgreSQL container, or database reset.

Example

tests/
  {ProjectName}.Domain.Tests/          invariants, closed sets, state transitions
  {ProjectName}.Application.Tests/     handlers, validators, result unions
  {ProjectName}.Web.Tests/             component rendering and interaction
  {ProjectName}.EndToEnd.Tests/        real browser flows

Requirement Each Case of a use case MUST be proved by an automated test whose steps call the use case and assert the Result.

Rationale A test proves a Case only when its steps call the use case and assert the Result. The link is then computed from the test rather than claimed in prose. A Case no test proves is recorded as a Known gap with an owner and an end date. This realizes litespec/frontend/testing#prove-a-case-by-calling-its-use-case.

Requirement A Domain or Application test MUST run with no browser, JavaScript host, or storage.

Rationale A core test needing an interop substitute indicates a layering defect, so the fix belongs in the layering rather than the test. This realizes litespec/frontend/testing#match-test-level-to-risk.

Requirement A component test MUST inject a test double for every Application interface, including interop.

Rationale Coverage includes keyboard interaction and the states each route declares. A component test starts no browser and asserts on user-visible output rather than markup structure. This realizes litespec/frontend/testing#keep-mocks-at-owned-boundaries and litespec/frontend/testing#test-observable-states.

Requirement A browser suite MUST cover the primary release flow, startup with storage unavailable, offline startup, and export followed by import.

Rationale These four are the paths where a client-only product loses user work, and none of them can be proved without a real browser. This realizes litespec/frontend/testing#match-test-level-to-risk.

Requirement CI MUST measure the compressed transfer size of the published framework payload and fail above the recorded budget.

Rationale Directory size does not describe what a visitor waits for, so the measurement uses transfer size. The measurement names the tool that produced it and the compression it applied. Two tools reporting different numbers for one payload make a budget unreviewable. A published size-limit tool holding the budget in its configuration is the baseline. A project-owned script recording the same two facts is equally valid.