testing-audit

Audit React test suites against Testing Library query priority and async patterns.

3|5|Updated Apr 26, 2026
One-click install
npx skills add https://github.com/BenSheridanEdwards/ArchitectPlaybook --skill testing-audit-bensheridanedwards
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing-audit
Source: https://github.com/BenSheridanEdwards/ArchitectPlaybook/tree/main/testing-audit
Command: npx skills add https://github.com/BenSheridanEdwards/ArchitectPlaybook --skill testing-audit-bensheridanedwards

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? React test suites often drift into brittle patterns: overuse of getByTestId, fireEvent instead of userEvent, oversized snapshots, and assertions against raw utility classes. This Skill statically audits a TypeScript and React project's tests against an opinionated four-layer baseline and produces structured findings plus an optional implementation plan. ## Core Features & Use Cases - Four-layer audit: Covers test runner and tooling, query priority and selector hygiene, interaction and async patterns, and test design and coverage, each graded as present, partial, missing, or violation. - Diagnostic snapshot: Measures query distribution across the Testing Library priority ladder, userEvent vs fireEvent ratios, snapshot sizes, and flaky-pattern signals, written to .architect-audits/testing-audit/. - Optional coverage enrichment: With --with-run, invokes Vitest or Jest in coverage mode and folds real coverage data into the findings; never runs Playwright or Cypress. - Use Case: Run the audit on a React codebase before a refactor to find tests coupled to implementation details, then accept the generated implementation plan that orders fixes by testing-philosophy impact. ## Quick Start Ask the assistant to run /testing-audit on this repository to audit the React tests and report the top findings.

Frequently Asked Questions about testing-audit

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

FAQPage Schema
How do I audit React Testing Library tests for best practices?▼

Run /testing-audit in the project root. It statically walks every test file, measures query priority distribution, userEvent vs fireEvent usage, and waitFor discipline, then writes findings to .architect-audits/testing-audit/ and offers an implementation plan.

What is the Testing Library query priority order?▼

Priority 1 covers accessible queries like getByRole, getByLabelText, and getByText; Priority 2 covers semantic queries like getByAltText and getByTitle; Priority 3 is getByTestId as a last resort. The audit expects at least 70 percent of queries in Priority 1 by default.

Does the testing audit support Vitest and Jest?▼

Yes, both Vitest and Jest are supported as test runners. With the --with-run flag it invokes the detected runner in coverage mode and parses the JSON output; Mocha and other runners are out of scope.

Can the audit run my Playwright or Cypress end-to-end tests?▼

No. The audit never runs Playwright or Cypress suites, even with --with-run, because end-to-end runs have side effects. It only detects their presence and checks for critical-path spec coverage statically.

Why does the audit flag snapshot tests and utility-class assertions?▼

Large or whole-component snapshots couple tests to implementation and churn on refactors, so snapshots over 100 lines are violations. Assertions like toHaveClass('bg-gray-100') break on theme changes; the audit requires semantic tokens or role and text assertions instead.

What happens when the project has no test runner installed?▼

The audit marks the runner foundation check as missing, marks runner-dependent checks as not-evaluated with reason test-runner-not-detected, and continues evaluating source-level test-design checks. It recommends installing Vitest or Jest in the findings.