e2e-testing

Validate end-to-end user workflows through the UI with Playwright.

1|Updated Apr 13, 2026
One-click install
npx skills add https://github.com/Inteligentsensingsolutions/tdd-dev-workflow --skill e2e-testing-inteligentsensingsolutions
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e-testing
Source: https://github.com/Inteligentsensingsolutions/tdd-dev-workflow/tree/main/skills/e2e-testing
Command: npx skills add https://github.com/Inteligentsensingsolutions/tdd-dev-workflow --skill e2e-testing-inteligentsensingsolutions

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Provide a clear, repeatable approach to verify complete user journeys through the UI so teams can catch regressions, flaky tests, and integration gaps before merging code. It reduces developer uncertainty by defining stable selectors, test structure, and debugging practices that surface visible outcomes instead of fragile internal assertions.

Core Features & Use Cases

  • Page Object Model: Encapsulate selectors and actions to keep tests readable and resilient to UI changes.
  • Descriptive test names & visible assertions: Write tests that map directly to acceptance criteria and assert what users see.
  • Async handling & wait strategies: Prefer condition-based waits and network response checks over fixed timeouts to reduce flakiness.
  • Test data isolation: Seed and clean test data via APIs to avoid cross-test interference.
  • CI and debugging support: Run headless in CI, retain traces and screenshots on failure, and use headed mode for local debugging.
  • Anti-pattern guidance: Avoid testing internal state, brittle selectors, hard-coded waits, and third-party UIs.

Quick Start

Use the e2e-testing skill to generate a Playwright E2E test for the critical user login journey using Page Object Model, data-testid selectors, and condition-based waits.

Frequently Asked Questions about e2e-testing

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

FAQPage Schema
How do I write Playwright E2E tests that don't become flaky in CI?

To prevent flaky Playwright E2E tests, use condition-based waits instead of fixed timeouts and seed test data via APIs for isolation. This approach ensures tests assert visible outcomes and run reliably headless in CI without timing failures.

What is the Page Object Model pattern for test automation?

The Page Object Model encapsulates UI selectors and actions into reusable components to keep tests readable and resilient. It prevents brittle selectors by centralizing element definitions, allowing test scripts to remain stable during UI changes.

How do I structure end-to-end tests for critical user workflows like login and payments?

Structure end-to-end tests by mapping descriptive test names directly to acceptance criteria for critical flows like login and payments. Assert visible user outcomes and use API seeding to isolate test data, verifying cross-page integrations without cross-test interference.

Can I run Playwright tests headless in CI and still debug failures?

Yes, you can run Playwright tests headless in CI while retaining debugging artifacts. The skill configures CI execution to save traces and screenshots on failure, enabling local headed mode debugging to inspect visible outcomes and network responses.

What are common anti-patterns to avoid in E2E test automation?

Common E2E test automation anti-patterns include testing internal state, using brittle selectors, hard-coded waits, and testing third-party UIs. Avoid these by asserting visible outcomes, using data-testid selectors, and preferring condition-based waits over fixed timeouts.