E2e testing

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

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.From its SKILL.md

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.

One thing to look at

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.

SKILL.md

2.6 KB, 580 tokens by cl100k_base, 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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most e2e browser skills give in 580 tokens

Counted across 499 of the 513 authors here whose files we hold, read 2026-09-06

Capture screenshots, videos, and traces on failurein 32 of 499, across 23 files
Close the browser when donein 22 of 499
Interact with elements using snapshot refsin 21 of 499, across 20 files
Wait for specific network responses instead of fixed timeoutsin 20 of 499, across 10 files
Keep tests independent with no shared statein 19 of 499, across 17 files
Use Page Object Model classes to encapsulate page interactionsin 19 of 499, across 9 files
Locate elements with data-testid attributesin 19 of 499, across 10 files
Quarantine flaky tests with fixme or skipin 17 of 499, across 7 files
Upload test artifacts after every CI runin 17 of 499, across 8 files
Wait on conditions instead of using fixed sleepsin 17 of 499, across 13 files
Clean up test data after each testin 17 of 499, across 16 files
Test user-visible behavior, not implementation detailsin 16 of 499, across 10 files

Said here and by no other author read

Drive only the journey under test through the UI
Rank journeys by revenue and support-ticket risk
Delete tests whose failure no one would act on
Isolate each run's data with unique identifiers
Push edge cases and validation down to lower test layers
Follow the team's chosen runner over shown syntax

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.