E2E Testing Flow

For features that need end-to-end test coverage, use the E2E testing workflow. This creates comprehensive, reliable Playwright test suites for critical user journeys.

The route accepts a task description, Jira ID, standalone *.research.md, or *.plan.md. Missing research or plan companions trigger preparation and never authorize no-plan implementation. Before the first file-changing delegation, the Engineering Manager requires Human approval of the exact current plan revision. Automated tsh-plan-reviewer APPROVED is Reviewer approval only, not permission to implement; a material revision after Human approval requires Reviewer re-review and renewed Human approval.

On every delegated or direct E2E execution-owner entry path, the owner validates the referenced plan from disk before changing files. If validation fails, it fails closed, names the exact failed field, condition, or file, and uses vscode/askQuestions to offer recovery choices: point to the correct plan path, obtain Human approval for an existing plan, start plan preparation, or, for a delegated subagent, hand back to tsh-engineering-manager as one offered choice. The answer is never Human approval; only Human Approval of the exact current plan revision authorizes implementation.

Command Sequence

1️⃣ /tsh-implement <JIRA_ID or task description>
   ↳ 🔍 Engineering Manager delegates to Context Engineer for research
   ↳ 📖 Review research doc – understand feature scope and user journeys
   ↳ ✅ Identify critical paths that need E2E coverage
   ↳ 🧱 Engineering Manager delegates to Architect for planning
   ↳ 📖 Review plan – confirm test scenarios and acceptance criteria
   ↳ ✅ Human approves the exact current plan revision and ensures E2E testing is included
   ↳ 🧪 Engineering Manager delegates E2E tasks to the E2E Engineer agent
   ↳ 📖 Implements Page Objects, test files, and fixtures
   ↳ ✅ Run tests locally, verify they pass
   ↳ 🔄 Iterate on flaky or failing tests

tip

E2E test implementation is handled by the Engineering Manager as part of the standard /tsh-implement workflow. When the plan contains E2E test tasks, the Engineering Manager automatically delegates them to the E2E Engineer agent using the internal tsh-implement-e2e prompt.

What the E2E Engineer Does

When delegated to by the Engineering Manager, the E2E Engineer:

• Analyzes the application, designs test scenarios, and implements Page Objects.
• Uses Playwright MCP for real-time browser interaction and test verification.
• Follows BDD-style scenarios with proper Arrange-Act-Assert structure.
• Maps acceptance criteria to test scenarios.
• Verifies tests pass consistently (3+ consecutive passes) in headless mode before committing.

What It Produces

• Page Objects — Reusable page abstractions with accessibility-first locators.
• Test files — Comprehensive test suites following the should [behavior] when [condition] naming pattern.
• Fixtures — Test data and setup utilities.
• Execution report — Summary of coverage, results, and any issues found.

Testing Standards

The E2E Engineer agent enforces these standards:

Standard	Approach
Locators	Use getByRole, getByLabel, getByText. Avoid CSS selectors. Use getByTestId only as fallback.
Synchronization	Built-in auto-waiting assertions. No waitForTimeout(). No waitForLoadState('networkidle').
Test data	Dynamic data for every run (timestamps/UUIDs). Tests must not depend on state from other tests.
Security	Never hardcode credentials. Use environment variables.
Naming	should [behavior] when [condition] pattern.

Important

The E2E Engineer agent generates tests using Playwright MCP for real-time browser interaction. Always run the generated tests locally, review test scenarios for completeness, and verify they cover the critical user journeys identified during research.