Test Review – Unit Test Quality Review Skill

Review unit tests for quality, coverage, consistency, and adherence to established codebase patterns.

Usage

/test-review [path]

Where:

• [path] – Optional. Directory or file to review. Defaults to the entire test suite.

Examples

/test-review                           # Review all tests
/test-review spec/                     # Review Ruby specs
/test-review tests/unit/               # Review specific directory
/test-review src/__tests__/auth.test.ts  # Review specific file

Review Criteria

This skill evaluates tests against five key areas:

1. Test Volume – No Overabundance

Flags:

• Multiple tests covering identical behavior with trivial variations
• Excessive permutation testing (e.g., testing every input combination when a few representative cases suffice)
• Tests for trivial getters/setters with no logic
• Redundant assertions that test the same thing multiple ways
• Tests that duplicate integration test coverage unnecessarily

Guidance:

• Each test should earn its place by covering distinct behavior
• Prefer fewer, more meaningful tests over many superficial ones
• “One assertion per test” is a guideline, not a rule—test logical units of behavior

2. Test Coverage – No Critical Gaps

Flags:

• Missing tests for public API methods
• Untested error handling and edge cases
• No tests for critical business logic
• Missing boundary condition tests
• Untested state transitions
• No tests for recently modified code

Guidance:

• Focus coverage on code with high complexity or business impact
• Ensure error paths are tested, not just happy paths
• Test boundaries: empty inputs, nulls, max values, off-by-one scenarios

3. Uniformity – Consistent Test Structure

Flags:

• Inconsistent test naming patterns within the same project
• Mixed describe/context/it nesting styles
• Varying setup patterns (beforeEach vs inline setup)
• Inconsistent assertion styles
• Mixed approaches to test data creation

Guidance:

• Tests in the same project should feel like they were written by one person
• Follow the dominant pattern, even if you prefer something else
• Consistency aids readability and maintenance

4. Pattern Adherence – Respect Existing Conventions

This is the most critical review criteria.

Before suggesting any change, first discover what patterns exist in the codebase:

Discovery Steps:

1. Identify the test framework and version in use
2. Find existing test files (minimum 3-5 representative files)
3. Document observed patterns for:
   • File naming (*.test.ts, *_spec.rb, *Test.java, etc.)
   • Directory structure (__tests__/, spec/, test/, etc.)
   • Describe/context/it block organization
   • Setup and teardown approaches
   • Mocking/stubbing libraries and patterns
   • Factory/fixture usage
   • Assertion style
   • Test data patterns

Flags:

• Introducing new mocking libraries when one is already established
• Using different factory patterns than existing tests
• Changing describe block organization style
• Introducing new assertion matchers without justification
• Adding test utilities that duplicate existing helpers

Guidance:

• New patterns require extraordinary justification
• “I prefer it this way” is not justification
• If the existing pattern is genuinely problematic, flag it for discussion rather than silently changing it

5. Runnability – Tests Must Pass

Verification Steps:

1. Identify the test command from package.json, Makefile, or project docs
2. Run the test suite (or relevant subset)
3. Capture any failures, errors, or warnings

Flags:

• Tests that fail
• Tests that are skipped without explanation
• Missing dependencies that prevent test execution
• Environment setup issues
• Flaky tests (pass/fail inconsistently)

Guidance:

• All tests should pass before review is complete
• Skipped tests should have comments explaining why
• Tests should run in isolation without external dependencies

Review Process

Phase 1: Discovery – Understand Existing Patterns

Before reviewing any new or changed tests:

1. Locate test configuration:

   # Find test config files
   ls -la jest.config* vitest.config* .rspec* pytest.ini* phpunit.xml*
   

2. Sample existing tests:

   • Read 3-5 established test files
   • Document the patterns observed
   • Note any helper files, factories, or shared setup

3. Identify test command:

   • Check package.json scripts
   • Check Makefile targets
   • Check CI configuration

Phase 2: Analysis – Review Against Criteria

For each test file under review:

1. Check Volume:

   • Count tests vs. lines of source code being tested
   • Identify any obvious redundancy
   • Flag tests that don’t add coverage value

2. Check Coverage:

   • Compare public methods to test coverage
   • Identify untested branches
   • Note missing edge cases

3. Check Uniformity:

   • Compare structure to other test files
   • Note style inconsistencies
   • Check naming conventions match

4. Check Pattern Adherence:

   • Compare mocking approach to established pattern
   • Check factory/fixture usage matches existing
   • Verify describe block organization follows convention

Phase 3: Execution – Verify Tests Run

# Run the tests
npm test           # or
yarn test          # or
bundle exec rspec  # or
pytest             # or
go test ./...      # etc.

Capture and report:

• Pass/fail status
• Any skipped tests
• Coverage metrics if available
• Runtime warnings

Phase 4: Report – Structured Output

Output a review in this format:

## Test Review Report

### Summary
[1-2 sentence overall assessment]

### Existing Patterns Observed
| Pattern | Observed Convention |
|---------|---------------------|
| Test Framework | [e.g., Jest 29, RSpec 3.12] |
| File Naming | [e.g., `*.test.ts`] |
| Directory Structure | [e.g., `__tests__/` alongside source] |
| Mocking | [e.g., jest.mock with manual mocks in `__mocks__/`] |
| Factories | [e.g., Factory Bot with factories in `spec/factories/`] |
| Assertion Style | [e.g., expect().toEqual()] |

### Test Execution Results
- **Status:** [PASS/FAIL]
- **Total Tests:** [N]
- **Passed:** [N]
- **Failed:** [N]
- **Skipped:** [N]
- **Coverage:** [X% if available]

### Issues Found

#### Volume Concerns
[List any redundant or excessive tests]

#### Coverage Gaps
[List missing tests with severity]

#### Uniformity Issues
[List inconsistencies with file:line references]

#### Pattern Violations
[List deviations from established patterns - MOST IMPORTANT]

#### Runnability Issues
[List any test failures or execution problems]

### Recommendations
[Prioritized list of suggested changes]

### Approved Patterns
[Note tests that exemplify good practices]

Quick Reference

Trigger Phrases:

• “/test-review”
• “review my tests”
• “check my test coverage”
• “are my tests good”
• “review the test file”
• “analyze my unit tests”

Key Principles:

1. Pattern adherence is paramount – Never introduce new patterns without extraordinary justification
2. Discover before prescribing – Always understand existing conventions first
3. Quality over quantity – Fewer meaningful tests beats many trivial ones
4. Tests must run – A failing test suite is the top priority to fix

Review Priority Order:

1. Runnability (tests must pass)
2. Pattern adherence (respect existing conventions)
3. Coverage gaps (critical paths must be tested)
4. Uniformity (consistency matters)
5. Volume concerns (remove redundancy)