← ClaudeAtlas

review-testing-practiceslisted

Use when reviewing unit, integration, Storybook, component, or e2e tests against repository-local testing conventions: co-location, network mocking, MSW-style boundary mocks, behaviour assertions, deterministic waits, smoke/full split, locator priority, and screenshot-test discipline. Dispatched by review-orchestrator for --testing-practices, --project-conventions, --all, or changed test/e2e/story files.
MrCipherSmith/helyx · ★ 1 · Testing & QA · score 68
Install: claude install-skill MrCipherSmith/helyx
# Review — Testing Practices Reviewer for local testing discipline. Read project test guides first when present, then apply the neutral baseline below. --- ## Scope Applicable paths commonly include: - `**/*.test.ts`, `**/*.test.tsx`, `**/*.spec.ts`, `**/*.spec.tsx` - `**/*.integration.test.ts`, `**/*.integration.test.tsx` - `**/*.msw.ts`, `test/**`, `src/test/**` - `*.stories.tsx`, Storybook specs - `e2e/**`, Playwright/Cypress page objects and fixtures If the repository has local test documentation, cite the relevant convention in findings. --- ## Checklist ### Test Location and Tiers - Tests live near the code they cover unless the repository has a deliberate central test layout. - Shared test infrastructure folders are not used as buckets for feature tests. - Unit, integration, component, and e2e tiers are named and routed consistently. - Fast feedback lanes stay fast; screenshot/component/e2e suites are not used for cheap unit assertions. - Coverage gates focus on changed risk, not low-value tests for trivial getters. ### Network and Boundary Mocking - For data-fetching UI, prefer rendering the real component/store and mocking only the network boundary. - Avoid mocking the API module in integration tests when the repository has network-level mock infrastructure. - Unhandled network requests fail loudly instead of silently hitting the real world. - Mock handlers/fixtures are colocated and reusable by tests/stories where practical. - Handler paths match t