Testing
Run contract, unit, Workers, API, and desktop/mobile tests, including the compiled Worker.
Separate evidence levels
Passing types does not prove HTTP behavior, and local Worker tests do not certify real payments or mail delivery. Record the source commit, commands, outcomes, and outstanding acceptance for each run. Old passing counts do not certify a newer commit.
Prepare locally
Use Node 22.12+ and pnpm 10.26.2:
pnpm install --frozen-lockfile
pnpm muse:initAPI/browser suites use the initialized local app, defaulting to http://localhost:3000. Check that any reused development service belongs to the current checkout. Unit and Workers suites should not silently call real gateways or remote inference.
Run the layers
pnpm check:contracts
pnpm check:error
pnpm test:unit
pnpm test:workers
pnpm build
pnpm type-check
pnpm test:api
pnpm test:e2e| Command | Evidence |
|---|---|
| check:contracts | Repository and protected contract constraints |
| check:error | Biome diagnostics |
| test:unit | Configuration, functions, and business boundaries |
| test:workers | Local Worker runtime and isolated D1 behavior |
| build | Vite/TanStack/Cloudflare compilation and generation |
| type-check | TypeScript; build first on a fresh checkout for generated modules |
| test:api | HTTP, authorization, and service responses |
| test:e2e | Desktop and Chromium mobile-viewport interactions |
If generated route or Paraglide modules are missing, build rather than hand-writing empty replacements. Workers tests must use isolated data rather than production D1.
Test the compiled Worker
Stop your own development service on port 3000, build, then use PowerShell:
$env:FLARE_TEST_PREVIEW = '1'
pnpm exec playwright test
Remove-Item Env:FLARE_TEST_PREVIEWThe configuration starts pnpm preview and does not reuse a normal dev server. Keep the port available and distinguish development results from compiled-runtime evidence. FLARE_TEST_URL explicitly selects an existing server and disables automatic startup; do not point suites at the public demo or production without explicit acceptance scope.
Required scenarios
Exercise default email-code sign-in, new-address registration, password fallback, recovery, OAuth, and two-factor. Check isolation with two users, file keys and revocation, upload/download/delete and limits, streaming/credit failure/task compensation, and duplicate queue delivery.
Inspect admin filtering/pagination within loaded data and object-specific confirmations. Check both languages, all appearance modes, keyboard access, mobile drawers, and page overflow. Source scenarios live in tests/e2e/SCENARIOS.md; maintain behavior assertions rather than tests that merely repeat component implementation.
Real service acceptance
Record your deployment origin, health environment, HTTPS callbacks, actual mailbox receipt, enabled gateways' sandbox payments/webhooks, and real AI/queue results separately. CLI smokePassed and manual verified express different evidence.
Keep relevant traces and errors, removing credentials, codes, and personal data before sharing. Continue with deployment and troubleshooting.