test-quality-inspector

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