E2e testing

Skill Marcdaou/claude-qa-suite/qa-suite/skills/e2e-testing

Claude Code plugin marketplace: qa-suite — end-to-end QA (API, E2E, SEO, security, payments) for Next.js + Supabase + Stripe apps

Install

npx -y skills add Marcdaou/claude-qa-suite --skill e2e-testing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Write and run TypeScript end-to-end browser tests with Playwright that exercise real user journeys — signup/login, search, the booking flow, and Stripe checkout → confirmation. Use this skill whenever the user wants an e2e test, a browser test, to test a full flow "end to end", to catch regressions before deploy, or to verify the live site still works after a change. Trigger even on casual asks like "make sure booking still works in the browser" or "test the checkout flow".

SKILL.md

3.8 KB, as published. Nobody here has run it

TypeScript End-to-End Testing

An e2e test proves the whole stack works together the way a user experiences it: the browser, the Next.js app, Supabase, and Stripe all in one flow. These are the tests that catch "the button does nothing" and "checkout 500s on deploy" — things unit and API tests miss. They're also the slowest and flakiest, so the craft is in writing flows that are stable: resilient selectors, explicit waits on state, and no reliance on timing.

Setup

If the project has no Playwright yet, scaffold it:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/e2e/scaffold.sh

This installs @playwright/test, drops a playwright.config.ts tuned for Next.js

Vercel preview URLs (reads BASE_URL, retries on CI, traces on first retry), and creates e2e/ with a fixtures file. If Playwright already exists, skip the scaffold and just add specs under the existing test dir.

Writing stable tests

The difference between a test suite people trust and one they ignore is flakiness. Follow these because each one removes a class of flake:

Select by role or test id, not CSS. getByRole('button', { name: /book now/i }) survives restyling; .btn-primary-2 does not. Add data-testid to elements that have no accessible name. Selectors coupled to layout are the #1 source of flake.
Wait on state, never on time. Use web-first assertions (await expect(page.getByText('Booking confirmed')).toBeVisible()) which auto-retry. Never waitForTimeout — it's either too short (flake) or too long (slow suite).
Isolate auth. Log in once in a setup project and reuse storageState so each test starts authenticated without re-running the login UI. See the fixtures file.
Own your test data. Create the listing/booking the test needs (via API or a seed) and tear it down, so tests don't depend on each other or on prod data.

The booking flow — the spec that matters most

Wanderlust Stays' core journey. Encode it as one readable test:

Search a destination + dates from the homepage.
Open a listing from results.
Select dates and proceed to checkout.
Complete payment using Stripe test mode (card 4242 4242 4242 4242, any future expiry, any CVC). Handle the Stripe iframe with frameLocator.
Assert the confirmation page shows the booking reference, and (optionally) that the booking now appears in the user's trips.

See references/playwright.md for a complete annotated example of this flow, including how to drive the Stripe Elements iframe and how to stub it when you only want to test the app's own logic.

Running

npx playwright test                 # all specs, headless
npx playwright test booking         # one flow
npx playwright test --ui            # interactive debugging
BASE_URL=https://<preview>.vercel.app npx playwright test   # against a deploy

Report results plainly: which flows passed, which failed, and for a failure point the user at the trace (npx playwright show-trace) rather than guessing.

When to hand off to the agent

For "build a full e2e suite" or "test all the critical flows", delegate to the e2e-test-runner agent — it maps the app's routes, scaffolds Playwright, writes the specs, runs them, and returns a pass/fail report with traces for failures.

Gives 0 of the 12 instructions most e2e browser skills give

Counted across 407 of the 410 authors here whose files we hold, read 2026-08-06

use page object model patternin 35 of 407, across 25 files
Snapshot to get element refsin 24 of 407, across 14 files
keep tests independentin 23 of 407, across 18 files
Interact using refs from the latest snapshotin 23 of 407, across 11 files
clean up test data after each testin 21 of 407, across 15 files
test user behavior not implementationin 20 of 407, across 14 files
quarantine flaky tests explicitlyin 19 of 407, across 10 files
wait for specific network conditionsin 18 of 407, across 8 files
re-snapshot after navigation or dom changesin 17 of 407, across 10 files
Detect running dev servers before writing test codein 17 of 407, across 7 files
use web-first assertionsin 17 of 407, across 14 files
capture screenshots or videos on test failurein 17 of 407, across 14 files

Said here and by no other author read

add specs under the existing test directory
add data-testid to elements without accessible names
wait on state using web-first assertions
isolate auth using storageState
create and tear down required test data
handle stripe iframe with frameLocator

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.