Fixing Tests

Fixing Tests

Invariant Principles

1. Tests catch bugs, not checkmarks. Every fix must detect real failures, not just pass.
2. Production bugs are not test issues. Flag and escalate; never silently "fix" broken behavior.
3. Read before fixing. Never guess at code structure or blindly apply suggestions.
4. Verify proves value. Unverified fixes are unfinished fixes.
5. Scope discipline. Fix tests, not features. No over-engineering, no under-testing.

Inputs

Input Modes

Detect mode from user input, build work items accordingly.

If unclear: ask user to clarify target.

WorkItem Schema

interface WorkItem {
  id: string;                           // "finding-1", "failure-1", etc.
  priority: "critical" | "important" | "minor" | "unknown";
  test_file: string;
  test_function?: string;
  line_number?: number;
  pattern?: number;                     // 1-8 from green mirage
  pattern_name?: string;
  current_code?: string;                // Problematic test code
  blind_spot?: string;                  // What broken code would pass
  suggested_fix?: string;               // From audit report
  production_file?: string;             // Related production code
  error_type?: "assertion" | "exception" | "timeout" | "skip";
  error_message?: string;
  expected?: string;
  actual?: string;
}

Phase 0: Input Processing

Dispatch subagent with /fix-tests-parse command. Subagent parses input (audit YAML, fallback headers, or general instructions) into WorkItems and determines commit strategy.

Phase 1: Discovery (run_and_fix only)

Skip for audit_report/general_instructions modes.

pytest --tb=short 2>&1 || npm test 2>&1 || cargo test 2>&1

Parse failures into WorkItems with error_type, message, stack trace, expected/actual.

Phase 2: Fix Execution

Dispatch subagent with /fix-tests-execute command. Subagent investigates, classifies, fixes, verifies, and commits each WorkItem.

2.3 Production Bug Protocol

PRODUCTION BUG DETECTED

Test: [test_function]
Expected behavior: [what test expects]
Actual behavior: [what code does]

This is not a test issue - production code has a bug.

Options:
A) Fix production bug (then test will pass)
B) Update test to match buggy behavior (not recommended)
C) Skip test, create issue for bug

Your choice: ___

Do NOT silently fix production bugs as "test fixes."

Phase 3: Batch Processing

FOR priority IN [critical, important, minor]:
    FOR item IN work_items[priority]:
        Execute Phase 2
        IF stuck after 2 attempts:
            Add to stuck_items[]
            Continue to next item

Stuck Items Report

## Stuck Items

### [item.id]: [test_function]
**Attempted:** [what was tried]
**Blocked by:** [why it didn't work]
**Recommendation:** [manual intervention / more context / etc.]

Phase 4: Final Verification

Run full test suite:

pytest -v  # or appropriate test command

Summary Report

## Fix Tests Summary

### Input Mode
[audit_report / general_instructions / run_and_fix]

### Metrics
| Metric | Value |
|--------|-------|
| Total items | N |
| Fixed | X |
| Stuck | Y |
| Production bugs | Z |

### Fixes Applied
| Test | File | Issue | Fix | Commit |
|------|------|-------|-----|--------|
| test_foo | test_auth.py | Pattern 2 | Strengthened to full object match | abc123 |

### Test Suite Status
- Before: X passing, Y failing
- After: X passing, Y failing

### Stuck Items (if any)
[List with recommendations]

### Production Bugs Found (if any)
[List with recommended actions]

Re-audit Option (if from audit_report)

Fixes complete. Re-run audit-green-mirage to verify no new mirages?
A) Yes, audit fixed files
B) No, satisfied with fixes

Special Cases

Flaky tests: Identify non-determinism source (time, random, ordering, external state). Mock or control it. Use deterministic waits, not sleep-and-hope.

Implementation-coupled tests: Identify BEHAVIOR test should verify. Rewrite to test through public interface. Remove internal mocking.

Missing tests entirely: Read production code. Identify key behaviors. Write tests following codebase patterns. Ensure tests would catch real failures.

Slow/bloated tests: Tests taking >5s often hide issues: heavy fixtures, unnecessary I/O, or oversized test data. Separate slow tests with marks (@pytest.mark.slow, @pytest.mark.integration, etc.) to preserve fast feedback on core functionality. Move real I/O to integration tier. Shrink test inputs to the minimum that exercises the behavior. If a fixture takes longer than the test itself, it is too heavy for a unit test.

Over-Engineering

• Creating elaborate test infrastructure for simple fixes
• Adding abstraction layers "for future flexibility"
• Refactoring unrelated code while fixing tests

Under-Testing

• Weakening assertions to make tests pass
• Removing tests instead of fixing them
• Marking tests as skip without fixing

Scope Creep

• Fixing production bugs without flagging them
• Refactoring production code to make tests easier
• Adding features while fixing tests

Blind Fixes

• Applying suggested fixes without reading context
• Copy-pasting fixes without understanding them
• Not verifying fixes actually catch failures

Self-Check

Before completing, ALL boxes must be checked. If ANY unchecked: STOP and fix.

• All work items processed or explicitly marked stuck
• Each fix verified to pass
• Each fix verified to catch the failure it should catch
• Full test suite ran at end
• Production bugs flagged, not silently fixed
• Commits follow agreed strategy
• Summary report provided

Fix it. Prove it works. Move on. No over-engineering. No under-testing.