| name | test-reviewer |
| description | Use this skill to review tests for false confidence, excessive mocking, meaningless assertions, and weak behavior coverage. Use after writing tests or when a suite passes but bugs still escape. |
| version | 0.1.0 |
Test Reviewer
Purpose
Evaluate whether tests provide real safety signals or merely appear to do so.
What to Look For
1. Excessive Mocking
- Mocks outnumber real objects
- Mock setup mirrors production logic
- Tests pass regardless of implementation correctness
- Mock verification replaces behavior verification
2. Fake Testing
- Assertions recreate implementation instead of validating outcomes
- Tests verify that mocks were called, not user-visible behavior
- Tests compare a value to itself or otherwise tautological checks
- Tests that execute code with no meaningful assertion
3. Weak Assertions
- Always-true or trivial assertions
- Missing assertions
- Hardcoded expected values that do not constrain behavior
- Assertions that would still pass for broken logic
4. Test Smells and Coverage Quality
- Excessive irrelevant setup
- Speculative scaffolding, redundant fixtures, or reinvented stdlib bloating the suite
- Brittle tests tightly coupled to implementation details
- Order-dependent or global-state-dependent tests
- Critical paths and edge cases untested
When trimming bloat, keep a single smoke / assert self-check as the minimum —
never delete the last line that fails when the logic breaks.
Review Process
- Check if tests fail when behavior is broken
- Evaluate whether mocks are necessary and justified
- Confirm test independence and deterministic setup
- Identify gaps in behavior coverage and edge cases
- Recommend stronger, behavior-focused rewrites
Output Format
Use this structure:
Critical Issues
Tests that provide false confidence.
Recommended Changes
High-impact rewrites that improve confidence.
Suggestions
Minor improvements for clarity and maintainability.
For each finding:
- Quote the problematic test code
- Explain what bug could slip through
- Provide a concrete improved test
- State what behavior the improved test verifies
Related
For build-time discipline (write the smallest test that catches the bug), pair
this with the ponytail skill.
Principles
- A test must fail when behavior is wrong
- Prefer behavior assertions over implementation assertions
- Use real dependencies when practical
- One test should validate one behavior
- Passing tests should correlate with working software
