For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/testing.md (or send Accept: text/markdown).
Testing strategy
Understand what deterministic, browser, database, and provider checks establish.
Setup and configuration
Before any step, read Before you start and Terminal basics. These instructions assume you opened the full supastack monorepo in VS Code; its root package.json marks the repository root. In pnpm commands, a workspace package is an app or shared-code folder; in the product, a workspace is a team's data container and security boundary. corepack pnpm --filter ... selects one package from the monorepo while commands run from its root. If you opened only a synced mobile or desktop folder, it does not contain the Web backend, Docker setup, or root scripts: run the backend from this monorepo or a reachable hosted server, and use the platform folder's own scripts. An environment variable is a named setting stored in a local .env file or your hosting dashboard; restart the relevant app after changing it, and keep server secrets out of NEXT_PUBLIC_ and EXPO_PUBLIC_ values.
1. Open the repository-root package.json to see the check commands.
2. From that root folder run corepack pnpm test for automated unit tests, then corepack pnpm --filter @supastack/web typecheck for Web TypeScript checks.
3. For browser behavior, start the Web app and run corepack pnpm test:e2e. Expected: each command reports its own result; a unit test does not prove that a real database, payment provider, email service, or phone works.
The default test suite uses deterministic fake/local adapters. Browser tests cover user interactions; database acceptance and external provider smoke are separate gates. Run checks relevant to the changed behavior before broadening the scope.
corepack pnpm test
corepack pnpm check
corepack pnpm build
corepack pnpm test:e2e
corepack pnpm test:e2e:productionCommands to copy
Follow the comments to see which folder a command runs in. If two terminals are labeled, open two terminal windows and keep the first command running while you use the second.
corepack pnpm test
corepack pnpm --filter @supastack/web typecheck
corepack pnpm test:e2eImplementation workflow
For behavior changes, write a failing acceptance test first. Pair successful access with denied anonymous and cross-workspace requests. For forms and task flows, verify loading, error, and recovery behavior as well as the happy path.
An intercepted browser response proves that the interface responds to that fixture. It does not prove authentication persistence, payment processing, provider delivery, or a physical device callback.
Verification and troubleshooting
If a database test says it was skipped, set up its isolated test database before reporting database coverage. If a Web tab is at port 3001, it is the separate apps/docs server; the kit Web app starts at port 3000. If Playwright fails on its first Windows run, let browser installation finish and rerun the failing command; never turn off system-wide security to work around it.
If a database-gated test skips, configure its isolated test database before claiming that gate passed. If a browser runner emits passing assertions but hangs during teardown, report both facts; a stuck process is not a clean successful command.
On Windows, an initial browser run may time out while Defender scans newly installed Playwright browsers or dependencies. Let installation finish, rerun the failed suite with corepack pnpm test:e2e or corepack pnpm test:e2e:production, and inspect its trace and Defender Protection History if it fails again. Leave system-wide protection enabled.
The local browser suite owns port 3100 and refuses to reuse a process already listening there. Set PLAYWRIGHT_PORT to a free port before corepack pnpm test:e2e if another app owns 3100; this prevents tests from silently targeting another project.