testing-gmv

Runs and debugs Vitest, Playwright E2E, and pytest suites for the PalFish GMV app.

1|Updated May 23, 2026
One-click install
npx skills add https://github.com/palfish-t-i-u/palfish-t-i-u-h-th-ng-ver-2 --skill testing-gmv-palfish-t-i-u
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testing-gmv
Source: https://github.com/palfish-t-i-u/palfish-t-i-u-h-th-ng-ver-2/tree/main/.claude/skills/testing-gmv
Command: npx skills add https://github.com/palfish-t-i-u/palfish-t-i-u-h-th-ng-ver-2 --skill testing-gmv-palfish-t-i-u

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It removes the guesswork of running, writing, and debugging the three independent test harnesses (Vitest unit, Playwright E2E, backend pytest) in the PalFish GMV repository, including environment setup, auth session handling, and known failure modes. ## Core Features & Use Cases - Full test stack coverage: Documents every npm script for Vitest unit tests (MSW mocks), six Playwright project groups (auth-setup, journeys, rbac-*, e2e), and the 338-test backend pytest suite. - Environment bootstrap: Guides fresh-clone setup including .env.e2e creation, sandbox test accounts, Playwright browser install, and xlrd for backend tests. - Gotchas & incident history: Records 12 known pitfalls such as stale Vite server reuse, Supabase JWT rotation invalidating sessions, fake auth on localhost dev, and MSW handlers covering only legacy endpoints. - Use Case: A developer fixes a reconciliation bug and asks to verify it — the skill runs the single matching E2E spec first, then escalates to the full suite only before merge, following the tiered validation loop. ## Quick Start Run the frontend unit tests and then the default E2E suite for the GMV app, and report any failures with suggested debugging commands.

Frequently Asked Questions about testing-gmv

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

FAQPage Schema
How do I run Playwright E2E tests for this project?

Run `cd frontend && npm run e2e` for the default suite, which triggers auth-setup first. Use `npm run e2e:journeys` for multi-step flows, `npm run e2e:rbac` for role-gating tests, or `npm run e2e:all` for everything. A `.env.e2e` file with sandbox credentials must exist first.

How do I run backend pytest tests in this repo?

Run `python -m pytest backend/tests/ -v` from the repository root, not from inside `backend/`. Running from the backend directory collects zero tests. Two tests fail without the xlrd package, fixable with `pip install xlrd`.

Why does Playwright fail with Missing .env.e2e error?

The `loadEnvE2e()` helper hard-throws when `frontend/.env.e2e` is absent or any required key is an empty string. Copy `.env.e2e.example` to `.env.e2e` and fill in the sandbox test account credentials such as E2E_EMAIL and E2E_PASSWORD.

Why do Vitest tests throw unhandled request errors with MSW?

The setup uses `onUnhandledRequest: 'error'`, so any HTTP call without a matching MSW handler throws immediately. The existing handlers in `src/test/msw/handlers.ts` cover only legacy endpoints, so new modules require adding corresponding handlers.

Should I use unit tests or E2E tests for a new feature?

Use Vitest unit tests for component logic with mocked APIs via MSW, and Playwright E2E for flows spanning real backend and Supabase auth. Note E2E runs serially with workers=1 against the sandbox, and journey tests create real `[E2E-TEST]`-prefixed data.

Why do E2E tests return 401 errors against the local dev server?

Localhost dev mode uses a fake `dev_user` localStorage stub with no real Supabase JWT, so backend calls return 401. To test against the deployed sandbox with real auth, run Playwright with `--config playwright.sandbox.config.ts`.