| name | test-quality-inspector |
| description | Verify that a test is actually testing what it claims to test: semantic correctness, mutation-style reasoning, and mock hygiene for any language or framework |
| user-invocable | true |
| disable-model-invocation | false |
| version | 1.0.0 |
| category | testing |
| license | Apache-2.0 |
| compatibility | claude-code |
| tags | ["testing","quality-assurance","test-review","mutation-testing","mocking","semantic-correctness"] |
| progressive_disclosure | {"entry_point":{"summary":"Inspect a test for semantic correctness: does it actually test what it claims? Would it catch real bugs?","when_to_use":"When reviewing a test file or test suite to verify it has meaningful assertions, correct coverage of the named behavior, and would genuinely fail if the implementation broke.","quick_start":"1. Identify the test(s) to inspect (file path or pattern). 2. Read the test and the implementation. 3. Apply the five checks below. 4. Produce a verdict with evidence. 5. Suggest concrete fixes."},"references":["checks.md","verdicts.md","mock-hygiene.md","mutation-reasoning.md"]} |
Test Quality Inspector
Overview
A passing test is not the same as a good test. This skill inspects tests for semantic correctness — whether the test actually verifies the behavior it claims to verify, not just whether it runs without error.
Apply this skill to any test file or suite, in any language or framework.
When to Use
Activate when:
- Reviewing a PR that includes new or modified tests
- A test passes but a bug still shipped
- Test names feel mismatched to their assertions
- Mocks seem unusually extensive
- Coverage numbers look good but confidence is low
- Preparing to refactor and needing to trust the test harness
Arguments
This skill accepts optional arguments:
- File path:
path/to/test_file.py — inspect a specific file
- Test name pattern:
test_user_* — inspect tests matching the pattern
- No args: inspect all tests in the current context or most recently discussed test
Five-Step Inspection Process
Step 1: Read the Test
Read the test file completely. Identify:
- The test name and any docstring or description
- What the test sets up (fixtures, mocks, data)
- What action it performs (the "act")
- What it asserts (the "assert")
- What it does NOT assert
Step 2: Read the Implementation
Find and read the actual code being tested. Identify:
- The function/method signature
- All return values and side effects
- Branches and edge cases in the implementation
- What could realistically go wrong
Step 3: Apply the Five Checks
Run all five checks. See checks.md for detailed guidance.
Check 1 — Name-to-Assertion Alignment
Does the test name describe what the assertions actually verify? A test named test_returns_empty_list_when_no_results that only asserts len(result) == 0 without checking the type is subtly misleading.
Check 2 — Meaningful Assertions (No Tautologies)
Would the assertion pass even if the implementation returned garbage? Examples of hollow assertions:
assert result is not None when the function always returns an object
