Sauci/docs/testing/strategy.md

Testing strategy

Verification is layered so quick feedback stays cheap while user-facing behavior is proved through the real stack.

Gates

• verify:fast: invariant lint, workspace lint/typecheck, and unit tests.
• verify:full: fast gate plus builds and standalone API/PostgreSQL integration tests against a loopback database.
• verify:e2e: Playwright browser flows and native Maestro flows against an already-running local stack.
• verify: full plus E2E; this is the pre-PR target.

The required CI checks also run instrumented coverage for the API and mobile workspaces. Mobile coverage includes every TypeScript file under app and src, including files no test imports. The committed thresholds are ratchets, not targets: raise them as coverage improves, and never narrow the collected source set to make a percentage pass.

• API unit floor: 30% statements/lines, 60% branches, 40% functions.
• API PostgreSQL integration floor: 55% statements/lines, 65% branches/functions.
• Mobile floor: 23% statements/lines, 17% branches, 21% functions.

CI runs deterministic checks on every pull request and on pushes to staging and main. The backend integration job provisions disposable PostgreSQL and refuses non-loopback database URLs. User-facing browser/native acceptance remains a pre-promotion check because it requires running services and test identities.

Test ownership

• Unit/component tests live with their workspace.
• Standalone backend integration tests live in apps/api/test.
• apps/supabase/tests cover the retired data plane and are not a deployment gate.
• Cross-application browser tests live in e2e.
• Native black-box flows live in e2e/maestro.

E2E product-data endpoints must be local or staging, never production. Local database tests refuse non-loopback URLs. Authenticated staging acceptance uses the designated non-production hosted Auth project and disposable fixture users.