| name | test-coverage-quality-review |
| description | Use this skill when reviewing a test suite for assertion quality rather than coverage percentage — detecting coverage theater, where line/branch coverage is high but the tests would not catch a regression. Trigger when a user provides test files, a coverage report, or asks whether their tests are actually meaningful, why bugs ship despite high coverage, or how to set a coverage gate. This skill reviews test artifacts statically; it does not execute tests or run a coverage tool. |
| allowed-tools | Read Grep Glob |
| metadata | {"author":"github: Raishin","version":"0.1.0","updated":"2026-05-17","category":"delivery","lifecycle":"experimental"} |
Test Coverage Quality Review
Purpose
This skill reviews a test suite for whether its tests would actually catch a regression — not whether a coverage tool reports a high percentage. High line coverage with weak assertions is coverage theater: code runs during the test, the number looks good in CI, and the test still passes when the behavior breaks. The review separates exercised code from verified behavior, surfaces assertion-free and tautological tests, finds mock over-specification that tests the test instead of the system, and recommends a coverage gate that measures meaning rather than line execution.
Lean operating rules
- Treat a test with no assertion — it calls the code, no error is thrown, the test passes — as HIGH. Line coverage counts it; it verifies nothing.
- Treat tautological assertions (
expect(true).toBe(true), expect(result).toBe(result), snapshot tests auto-updated on every change without review) as HIGH — they cannot fail when behavior changes.
- Treat assertions that only check shape, not value (
expect(result).toBeDefined, expect(res.status).toBeTruthy, expect(arr.length).toBeGreaterThan(0)) where an exact value is knowable as MEDIUM — they pass for wrong values.
- Treat tests that assert the mock was called but never assert the result computed from it as HIGH — they test the wiring, not the behavior.
- Treat over-mocked unit tests where every collaborator is mocked and the assertions only restate the mock setup as HIGH — the test is a mirror of itself and proves nothing about integration.
- Treat the absence of error-path, empty-input, and boundary tests for code that has those branches as HIGH — the happy path inflates the coverage number while real failure modes are untested.
- Treat a coverage percentage gate as the sole quality signal as MEDIUM — a line-percentage threshold is easily satisfied by assertion-free tests; recommend pairing it with assertion-density and changed-line coverage.
- Treat snapshot tests as the primary verification for logic-bearing output as MEDIUM — snapshots detect change, not correctness, and decay into rubber-stamped updates.
- Treat coverage measured only as a global percentage with no per-changed-file or diff coverage as MEDIUM — new untested code hides behind a large tested codebase.
- Treat 100% coverage as a target presented as a goal as MEDIUM — it incentivizes theater; the goal is meaningful assertions on behavior that matters.
- Do not recommend raising the coverage threshold as a quality improvement — recommend assertion strength and diff coverage instead.
- Label every finding with evidence basis: test source provided, coverage report provided, documentation-based, or inference.
References
Load these only when needed:
Response minimum
Return, at minimum:
- Assertion quality findings (assertion-free, tautological, shape-only)
- Mock usage findings (call-assertion-only, over-mocking)
- Branch coverage gap assessment (error paths, boundaries, empty inputs)
- Coverage gate assessment (percentage-only vs. diff/assertion-aware)
- Snapshot test reliance assessment
- Severity-labelled finding list (critical / high / medium / low)
- Safe next actions
