Skip to content
Back to skills

E2e Test

ASecurity

Write an end-to-end test that drives the real app through a user flow with Playwright or Cypress

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsgotesting

Works with

  • cli

Security analysis

A100/100

Scanned September 3, 2026

npx -y skills add black141312/ada --skill e2e-test --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of E2e Test?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for E2e Test
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/black141312-e2e-test/badge)](https://www.skillsdirectory.com/skills/black141312-e2e-test)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: e2e-test
description: Write an end-to-end test that drives the real app through a user flow with Playwright or Cypress
category: testing
---

# E2E Test

Use when you need to verify a complete user journey through the running app, not isolated units.

1. Identify the user-facing flow and its success criteria (what the user does, what they should see/get at the end).
2. Set up the test against a real or test-seeded environment; ensure known starting state (logged-out, empty cart, etc.).
3. Drive the flow by user-visible interactions — click buttons, fill fields, follow links — as a real user would.
4. Locate elements by accessible role, label, or test id rather than brittle CSS/XPath tied to styling.
5. Assert on observable outcomes (visible text, URL, network result), using the framework's auto-waiting instead of fixed sleeps.
6. Run it headless and headed, confirm it passes repeatably, and wire it into CI.

## Rules
- Test critical paths end-to-end (signup, checkout, core action); keep E2E count small since they are slow and costly.
- Select elements by role/label/`data-testid`, never by auto-generated class names or deep DOM position.
- Rely on built-in waiting for conditions; never paper over timing with `sleep`/fixed `waitForTimeout`.
- Seed and reset state per test so runs are independent and repeatable; don't depend on leftover data.
- Keep secrets and base URLs in env/config, not hardcoded, so the test runs across local/CI/staging.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…