add-e2e-test

Generate Playwright end-to-end tests for user flows with assertions.

22|3|Updated Jul 28, 2024
One-click install
npx skills add https://github.com/webdevcody/go-mailing-list --skill add-e2e-test-webdevcody
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: add-e2e-test
Source: https://github.com/webdevcody/go-mailing-list/tree/main/.claude/skills/add-e2e-test
Command: npx skills add https://github.com/webdevcody/go-mailing-list --skill add-e2e-test-webdevcody

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you add dependable Playwright end-to-end tests for real user flows, reducing regressions and flaky UI checks by enforcing a safe, structured process.

Core Features & Use Cases

  • Flow-focused E2E testing: Creates one user-path test per flow (e.g., sign-in, multi-step wizard, payment, navigation) to keep failures easy to diagnose.
  • Playwright convention inheritance: Detects existing Playwright setup (package.json, config, existing spec locations) and follows the repo’s established patterns.
  • Flake-resistant implementation: Uses role- and label-based selectors and Playwright’s auto-retrying expect(...) assertions rather than brittle timeouts.
  • Hard-gated smoke test: Runs a minimal “app loads” test against the real running dev server before writing the full flow, stopping early if the harness is broken.
  • Stability verification: Repeats the flow test multiple times to confirm it is stable.

Quick Start

Ask the Skill to add an end-to-end test for your chosen user flow, then confirm the start URL, the user action, and the observable outcome you want the test to verify.

Frequently Asked Questions about add-e2e-test

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

FAQPage Schema
How do I add a Playwright end-to-end test for a login flow?

To add a Playwright end-to-end test for a login flow, you define the start URL, user actions, and observable outcome. The test validates existing infrastructure, runs a smoke test, and generates flow-specific assertions using getByRole selectors and auto-retrying expects.

Why are my Playwright UI automation tests flaky?

Playwright UI automation tests are flaky due to brittle selectors and fixed timeouts. Using role- and label-based selectors with Playwright's auto-retrying expect assertions reduces flakiness. Repeating the test multiple times verifies stability and confirms reliable outcomes.

What is the best way to test a multi-step wizard with Playwright?

The best way to test a multi-step wizard with Playwright is creating one user-path test per flow. This approach keeps failures easy to diagnose by validating existing test infrastructure, running a hard-gated smoke test, and asserting observable outcomes with auto-retrying expects.

Do I need to install Playwright separately before adding E2E coverage?

You may need to install Playwright separately before adding E2E coverage. The process detects existing Playwright setup in package.json and config files, optionally proposes explicit installation if missing, and inherits established baseURL and fixture patterns from your repository.

How does a smoke test prevent broken Playwright test harnesses?

A smoke test prevents broken Playwright test harnesses by running a minimal app loads check against the real dev server before writing the full flow. This hard-gated check stops early if the test infrastructure is broken, ensuring reliable end-to-end coverage.