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.