test-implement
test-implement provides reference patterns for implementing unit, integration, and end-to-end tests across different testing frameworks and tools. Use this skill when writing React component tests with RTL, Vitest, and MSW, or when implementing browser-based E2E tests with Playwright, ensuring tests follow AAA structure, maintain independence, and use behavior-focused naming conventions.
git clone --depth 1 https://github.com/shinpr/claude-code-workflows /tmp/test-implement && cp -r /tmp/test-implement/dev-workflows-frontend/skills/test-implement ~/.claude/skills/test-implementSKILL.md
# Test Implementation Patterns ## Reference Selection | Test Type | Reference | When to Use | |-----------|-----------|-------------| | **Unit / Integration** | [references/frontend.md](references/frontend.md) | Implementing React component tests with the repository's configured runner and network mocking layer | | **E2E** | [references/e2e.md](references/e2e.md) | Implementing browser-level E2E tests in the existing harness, or Playwright when the approved work introduces a harness | ## Common Principles ### AAA Structure All tests follow **Arrange-Act-Assert**: - **Arrange**: Set up preconditions and inputs - **Act**: Execute the behavior under test - **Assert**: Verify the expected outcome ### Test Independence - Each test runs independently without depending on other tests - No shared mutable state between tests - Deterministic execution — mock random and time dependencies ### Naming - Test names describe expected behavior from user perspective - One test verifies one behavior
Generates integration/E2E test skeletons from Design Doc ACs using ROI-based selection and journey-based E2E reservation. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
Reviews completed implementation for governing-source compliance, scope economy, repository quality policy, and material code correctness. Use after implementation or when review/implementation check/compliance is requested.
Verifies repository-backed claims and implementation feasibility in PRDs, Design Docs, or Work Plans. Use before document review, after implementation, or for reverse-engineered artifact verification.
Collects compact repository evidence for scope confirmation, technical option selection, complete design, and verification. Use before Design Doc creation when repository facts can change scope, reuse, contracts, cost, or proof.
Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.
Reviews one document or one ADR batch against governing requirements, repository evidence, and the needs of its next consumer. Use before user approval or when document consistency and completeness need verification.
Reviews changed integration and E2E tests against skeletons, proof obligations, or explicit prompt claims. Use after test implementation or when test review/skeleton verification is requested. Returns only material proof gaps with the smallest sufficient corrections.
Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.