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…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.