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 RTL + Vitest + MSW | | **E2E** | [references/e2e.md](references/e2e.md) | Implementing browser-level E2E tests with Playwright | ## 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 — no random or time dependencies without mocking ### 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.
Validates Design Doc compliance and implementation completeness from third-party perspective. Use PROACTIVELY after implementation completes or when "review/implementation check/compliance" is mentioned. Provides acceptance criteria validation and quality reports.
Validates consistency between PRD/Design Doc and code implementation. Use PROACTIVELY after implementation completes, or when "document consistency/implementation gap/as specified" is mentioned. Uses multi-source evidence matching to identify discrepancies.
Analyzes existing codebase objectively for facts about implementation, user behavior patterns, and technical architecture. Use when existing code needs to be understood without hypothesis bias. Invoked before Design Doc creation to produce focused guidance for technical designers.
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 document consistency and completeness, providing approval decisions. Use PROACTIVELY after PRD/UI Spec/Design Doc/work plan creation, or when "document review/approval/check" is mentioned. Detects contradictions and rule violations with improvement suggestions.
Verifies consistency between test skeleton comments and implementation code. Use PROACTIVELY after test implementation completes, or when "test review/skeleton verification" is mentioned. Returns quality reports with failing items and fix instructions.
Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports only observations without proposing solutions.