app-e2e-tests

Author and run environment-aware Playwright end-to-end tests across Fusebase app environments.

5|2|Updated Feb 9, 2026
One-click install
npx skills add https://github.com/ryan-haver/fusebase-mcp --skill app-e2e-tests-ryan-haver
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: app-e2e-tests
Source: https://github.com/ryan-haver/fusebase-mcp/tree/main/apps/client-portal-dashboard/.claude/skills/app-e2e-tests
Command: npx skills add https://github.com/ryan-haver/fusebase-mcp --skill app-e2e-tests-ryan-haver

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams need one Playwright test suite that runs against every environment (dev, prod-test, prod) of a Fusebase project without hardcoding URLs, org ids, or credentials, while avoiding dangerous mistakes like locking out app access principals or running against the wrong stage. ## Core Features & Use Cases - Environment-aware scaffolding: Generate a Playwright harness via fusebase scaffold --template e2e where fusebase env supplies base URLs, org/app ids, and test users per environment. - Per-app and cross-app specs: One Playwright project per app from fusebase.json, with specs/common, specs/<appKey>, and specs/integration for cross-app portal flows. - Safe production testing: Stage guard specs, self-skipping fixtures, secret handling via PW_USER_<KEY>_PASSWORD, and CI templates for GitLab and GitHub. - Use Case: Convert a manually verified QA scenario into a role-differential Playwright spec, run it with FUSEBASE_ENV=dev npm test, then promote it to the prod-test environment. ## Quick Start Ask the AI to scaffold an environment-aware Playwright e2e suite for this Fusebase project and convert a manually verified scenario into a spec that runs against dev and prod-test.

Frequently Asked Questions about app-e2e-tests

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run the same Playwright tests against dev and prod environments?▼

Use one suite in tests/e2e and select the target with FUSEBASE_ENV, for example FUSEBASE_ENV=dev npm test then FUSEBASE_ENV=prod-test npm test. Environment files supply base URLs, org and app ids, and test users so specs contain no hardcoded values.

How do I convert a manual QA scenario into a Playwright spec?▼

Identify the role it runs under, map it to a fixture user, and write one spec per behavior asserting role-differential outcomes. Prefer data-testid selectors, run against dev first, then the prod-test environment.

How do I test cross-app or portal flows in Playwright?▼

Place cross-app specs in specs/integration, since they span multiple apps and have no single baseURL. The config adds an integration project that builds each app's URL via appBaseUrl(env, key), and you add integration to the CI matrix APP list.

Why did my app return Access Denied after creating a magic link?▼

createAppMagicLink appends a user principal, and if the app's principal list was empty this flips access to only listed principals, locking everyone else out. Set explicit access principals with fusebase app update --access before the first magic-link test run.

Why does the first Playwright request time out after a deploy?▼

The suite runs against a cold backend, so a first-request timeout is expected rather than flakiness. The playwright.config.ts is already sized for cold starts, so do not mask it with retries or per-call timeout overrides.

How do I manage test user passwords in CI pipelines?▼

Store passwords as PW_USER_<KEY>_PASSWORD in .env.<name> locally and as CI variables in pipelines, never in git. The harness falls back to process env variables, including env-suffixed forms like PW_USER_CLIENT_PASSWORD_PROD_TEST.