Test Audit

Deep review of test suite quality to find tests that give false confidence, encode bugs, duplicate coverage, or are so heavily mocked they can't catch real regressions.

Process

At a high level, you'll follow the steps below, then cross-reference load-bearing code with test imports. Importance can be ranked by production blast radius (which code is most depended-on — if you use gjalla, impact and change history surface this), recent bug history, and how deterministic the failure mode is.

Phase 1: Orient

Understand the project's test infrastructure before diving in.

1. Map test structure: Find all test directories, count files per directory, identify naming conventions (.test.ts, .pglite.test.ts, .integration.test.ts, etc.)
2. Identify test layers: Which tests use real databases (PGlite, SQLite)? Which mock the ORM? Which mock at the service boundary? Which use @vitest-environment node vs jsdom?
3. Identify critical components: What are the security boundaries, data access layers, and core business logic? These are where false confidence is most dangerous.

Phase 2: Hunt for anti-patterns

Launch parallel investigations across test layers. For each test file, read BOTH the test AND the source code it claims to test. The anti-patterns to find: