app-e2e-testslisted

Author and run environment-aware Playwright e2e tests for this Fusebase project. Use when: 1. Adding or scaffolding e2e tests (fusebase scaffold --template e2e), 2. Converting a manually verified scenario into a Playwright spec, 3. Running the same test set against dev and prod environments, 4. Wiring test users/fixtures per environment.
fusebase-dev/fusebase-flow · ★ 9 · Testing & QA · score 77

Install: claude install-skill fusebase-dev/fusebase-flow

# App E2E tests (environment-aware) One suite in `tests/e2e/`, same specs against every environment of the project. Environments (`fusebase env`) supply everything varying between stages: base URLs, org/app ids, test users. When e2e is being added as part of an environment migration, first follow the local guide **App Environment Migration Guide**, then use this skill for the Playwright harness and CI details. When adding e2e to an existing project, first follow the local guide **E2E Playwright Setup Guide**: audit environments, prefer non-prod targets, warn before any prod run, scaffold from the CLI template, and wire GitLab CI. ## Scaffold ```bash fusebase scaffold --template e2e --dir tests/e2e cd tests/e2e && npx playwright install chromium FUSEBASE_ENV=<env> npm test ``` ## Layout — one project per app `playwright.config.ts` generates **one Playwright project per app** in `fusebase.json` (`name` = the app's `key`, falling back to `subdomain`), each pinned to that app's env-effective URL. Specs live in: - `specs/common/**` — universal specs, run for EVERY app, app-aware via `test.info().project.name`. - `specs/<appKey>/**` — that app's own specs. **Adding an app:** give it a short `key` in `fusebase.json` (e.g. `probe`), `mkdir specs/<key>`, add specs, add the key to the CI matrix `APP` list. Run a single app with `--project=<appKey>`. **Cross-app / portal flows** (registration → access propagation across apps + portal) span more than one app and have NO singl