E2e testing

Skill Amey-Thakur/AI-SKILLS/skills/testing/e2e-testing

Plug-and-play skills and prompts for every AI coding agent

Install

npx -y skills add Amey-Thakur/AI-SKILLS --skill e2e-testing

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

2 things to look at

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
4 stars4 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 end-to-end tests that earn their cost by covering complete user journeys against stable selectors. Use when protecting a critical path like signup or checkout across the full stack.

SKILL.md

2.6 KB, as published. Nobody here has run it

End-to-end testing

An end-to-end (E2E) test drives the real application the way a user does: through the browser, across every layer, to a real result. Each one is slow, brittle, and costly to maintain, so it has to pay rent. A suite that retests every field validation through the UI collapses under flakiness and gets muted. Spend E2E tests only on journeys whose failure would cost real money or trust, and build them to survive cosmetic change.

Method

Test journeys, not pages. One test completes a goal a user cares about, end to end: register, add to cart, pay, see the confirmation. Field-level rules and error copy belong in faster tests, not a browser round trip.
Select by role or test id, never by styling. Target getByRole("button", {name: "Pay"}) or data-testid="submit-order", not .btn-primary:nth-child(3). Selectors tied to layout break on every redesign that changed no behavior.
Wait on state, never on the clock. Assert the app reached a condition, await expect(page.getByText("Order placed")).toBeVisible(), never sleep(3000). Fixed sleeps are the primary engine of E2E flakiness and slowness at once.
Seed data through the API, act through the UI. Create the account and catalog with fast backend calls, then drive only the journey under test through the browser. Building prerequisites by clicking multiplies both runtime and failure surface.
Keep the count small and the paths critical. A handful of journeys run on merge beats hundreds run nightly and ignored. Rank by revenue and support-ticket risk, and delete any test whose failure no one would act on.
Isolate each run's data. Unique emails and tenant ids per run let tests execute in parallel without colliding, and let a failed run leave diagnosable state instead of poisoning the next.

Signals

Does each test represent a path a real user takes to a real outcome, not a single widget?
Would a CSS refactor that preserves behavior leave every test green?
When one fails, does the trace point at a broken journey rather than a timing accident?

Boundaries

E2E is the narrow top of the pyramid, not where coverage lives: push edge cases and validation down to integration-testing and unit-test-design. Follow the team's chosen runner, Playwright, Cypress, or Selenium, over the selector and waiting syntax shown here.