/testing-audit

Audit a TypeScript and React project's tests against an opinionated baseline organised in four layers — test runner and tooling, query priority and selector hygiene, interaction and async patterns, test design and coverage — preceded by a diagnostic snapshot. Then offer to generate an implementation plan for the gaps.

The default mental model is React component tests written with @testing-library/react, plus end-to-end tests in Playwright or Cypress. Vitest and Jest are both supported as the test runner. Mocha and other runners are out of scope.

How this differs from neighbouring audits

Concern	Owner
Whether tests run at every lifecycle stage (pre-commit, pre-push, continuous integration)	`/quality-gates-audit`
Whether `eslint-plugin-testing-library` and `eslint-plugin-jest-dom` are configured	`/linting-audit`
Whether tests catch errors well (error boundaries, async error paths)	`/error-handling-audit`
Whether the tests themselves are well-formed: query priority, async patterns, design, coverage	`/testing-audit`
End-to-end accessibility scans (axe in Playwright/Cypress)	`/accessibility-audit`
End-to-end performance measurement (Lighthouse CI)	`/performance-audit`

When a single fix passes multiple audits (for example, configuring eslint-plugin-testing-library satisfies both /linting-audit and /testing-audit), every relevant audit surfaces the same gap so the user sees it once and resolves it once.