agentsclimarketplace

E2e playwright

Skill lennney/gate-all-skills/skills/website/e2e-playwright

Frontend/Next.js Claude Code Skills — curated + custom

Install
npx -y skills add lennney/gate-all-skills --skill e2e-playwright

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

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 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

End-to-end testing with Playwright in Next.js applications — user flow coverage, component testing, and CI integration. Use when writing E2E tests, debugging flaky tests, or setting up test infrastructure.

SKILL.md

3.7 KB, as published. Nobody here has run it

E2E Testing with Playwright

End-to-end testing strategy for Next.js applications using Playwright.

Setup

npm init playwright@latest
# Choose: TypeScript, tests/e2e/, add GitHub Actions

Recommended config (playwright.config.ts):

import { defineConfig } from '@playwright/test'
export default defineConfig({
  testDir: './tests/e2e',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  webServer: {
    command: 'npm run dev',
    port: 3000,
    reuseExistingServer: !process.env.CI,
  },
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
})

What to Test

Critical User Journeys

Test the paths users actually take, not every component:

✓ User can sign up → verify email → login → see dashboard
✓ User can create/edit/delete content
✓ User can complete checkout flow
✓ Error states: 404, 500, network failure
✓ Responsive breakpoints (mobile, tablet, desktop)

What NOT to Test with E2E

  • Unit-verifiable logic (test in Vitest/Jest)
  • Individual component states (test in Storybook/Component tests)
  • Visual snapshots of static content

Patterns

Page Object Pattern

// tests/e2e/pages/login.page.ts
export class LoginPage {
  constructor(private page: Page) {}

  async goto() { await this.page.goto('/login') }
  async login(email: string, password: string) {
    await this.page.fill('[name="email"]', email)
    await this.page.fill('[name="password"]', password)
    await this.page.click('button[type="submit"]')
  }
  async waitForDashboard() {
    await expect(this.page).toHaveURL(/\/dashboard/)
  }
}

Data Seeding

// tests/e2e/global-setup.ts — seed DB before test run
import { seedTestData } from './helpers/seed'

export default async () => {
  await seedTestData({
    user: { email: '[email protected]' },
    posts: 3,
  })
}

Mocking API/Network

// Block external requests, mock specific responses
await page.route('**/api/analytics', route => route.abort())
await page.route('**/api/posts/**', async route => {
  await route.fulfill({ json: { title: 'Mock post' } })
})

CI Integration

# .github/workflows/e2e.yml
name: E2E
on: [deployment_status]
jobs:
  test:
    if: github.event_name == 'deployment_status' && github.event.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx playwright install
      - run: npx playwright test

Debugging Flaky Tests

  1. Check trace (trace: 'on-first-retry') — Playwright captures full DOM + network + console
  2. Add await page.waitForLoadState('networkidle') after navigation
  3. Use toHaveURL / toHaveText instead of arbitrary timeouts
  4. Isolate tests — each test should be self-contained, no shared state

Checklist

  • Can every critical user journey be tested end-to-end?
  • Are Page Objects used for reusable page interactions?
  • Is test data seeded before the run and cleaned up after?
  • Is CI configured (Vercel deployment status trigger)?
  • Are traces/screenshots captured on failure?
  • No await page.waitForTimeout(N) — always wait for actual conditions
  • Responsive testing at mobile (375px) and desktop (1280px+) breakpoints

Gives 1 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 testhere, and in 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

  • Seed test data before the test run
  • Test responsive breakpoints at mobile and desktop
  • Configure E2E tests in continuous integration

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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.