e2e-testing

Orchestrate end-to-end acceptance tests against live systems with cross-step state and final-state assertions.

2|Updated Jun 8, 2026
One-click install
npx skills add https://github.com/HACK-WU/skills --skill e2e-testing-hack-wu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e-testing
Source: https://github.com/HACK-WU/skills/tree/main/skills/e2e-testing
Command: npx skills add https://github.com/HACK-WU/skills --skill e2e-testing-hack-wu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Verifying that a full business journey (register → order → pay) actually works across real services, databases, and message queues is usually done by manual clicking and eyeballing. This Skill turns that into a structured, AI-orchestrated workflow that runs real operations against a live system and validates cross-component final state against requirement specs. ## Core Features & Use Cases - Journey Orchestration: Define Scenarios as typed Steps (api, db, ui, mq, cli, wait, assert, setup, teardown) with dependency ordering and a shared Context that passes outputs (e.g., user_id, order_id) between steps. - Black-Box Acceptance: Assertions anchor to requirement/design documents via requirement_ref, never to internal code, keeping e2e physically separated from unit tests in tests/e2e/. - Safety Gates & Secret Externalization: Dangerous write/delete operations require explicit user confirmation, credentials are masked in reports, and all secrets load from .env.e2e (fallback .env) instead of being hardcoded. - Dynamic Experience Validation: After e2e passes, the agent operates the feature like a real user (white-box planning, black-box execution) to evaluate feedback quality and error friendliness. - Use Case: Ask the agent to run a full register-and-order journey on staging; it creates the user, places the order, verifies the DB row, waits for async inventory deduction, checks the order.created event, cleans up test data, and outputs a journey report. ## Quick Start Ask the agent to run an end-to-end verification of the complete user registration and order placement flow against the staging environment and report whether the final cross-system state matches the requirements.

Frequently Asked Questions about e2e-testing

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

FAQPage Schema
How do I write an end-to-end test for a full business flow?

Define a Scenario with a requirement_ref, then break the journey into typed steps (api, db, mq, wait) with depends_on ordering. Each step declares produces keys so downstream steps reference outputs via ${ctx.data.key}, and a teardown step cleans up created data.

What is the difference between e2e testing and API testing?

API testing validates a single HTTP endpoint's connectivity and business assertions with constructed data. End-to-end testing orchestrates multiple real operations across services, passing state between steps and verifying cross-component final state like database rows and published events.

How do I keep e2e tests separate from unit tests in CI?

Place all e2e artifacts under tests/e2e/ and exclude that directory from unit test collection, for example with norecursedirs in pytest or testPathIgnorePatterns in jest. Run e2e as a separate CI job with its own environment file.

How do I handle secrets and credentials in e2e test definitions?

Never inline real tokens, URLs, or passwords in scenario files. Reference them as ${ENV.XXX} placeholders and store real values in a gitignored .env.e2e file (falling back to .env), committing only an .env.e2e.example template.

How do I test asynchronous eventual consistency in e2e flows?

Use a wait step that polls a condition with a timeout instead of asserting immediately. For example, after creating an order, poll until inventory is decremented before running database or message queue checks, avoiding flaky failures.

When should I not use end-to-end testing?

Skip e2e when you only need single-endpoint checks (use API testing), when logic can be mocked (use unit tests), or when a lightweight browser smoke check suffices. E2e requires a real running environment and is slower by design.