debug-delta-minimize

Delta Debugging — Test Case Minimization

The goal is to find the essential elements that trigger the bug. Everything else is noise that makes debugging harder. A minimal reproduction is a gift — it makes the root cause obvious.

The core insight: if you can reproduce the bug with 5 lines instead of 500, the 5 lines tell you exactly what's triggering it.

Core Algorithm

1. Start with full failing test case T
2. While reduction is possible:
   a. Generate a smaller candidate C from T
   b. Verify: does C still trigger the bug?
   c. If yes → accept reduction (T = C)
   d. If no → try a different reduction
3. When no further reduction is possible → T is minimal

Ask the user for:

1. The current failing test case (code, data, config — whatever triggers the bug)
2. The exact failure signal (error message, wrong output, crash)
3. How to verify if the bug still occurs (run command, manual step)

Phase 1: Initial Setup

Capture the current state:

• What is the input/code/data that triggers the bug?
• What is the expected behavior?
• What actually happens?
• How reproducible is it? (100% / intermittent)

Measure initial complexity:

• Lines of code / size of data / number of configuration parameters
• This becomes your baseline; track reduction percentage

Phase 2: Reduction Strategy

Choose the right strategy for the type of input:

For Code/Tests

1. Statement removal — try deleting lines one at a time; keep deletions that preserve the bug
2. Function inlining — replace function calls with their minimal implementation
3. Loop minimization — reduce loop iterations to the minimum needed
4. Conditional removal — eliminate branches that don't affect the bug path

For Data Inputs

1. Binary reduction — try half the data; if bug persists, discard the other half
2. Field elimination — for structured data (JSON/XML), try removing fields one by one
3. Value simplification — replace complex strings with "a", large numbers with 0 or 1, deep objects with {}

For Configuration

1. Parameter elimination — try removing settings; keep only what changes behavior
2. Default substitution — replace custom values with defaults; bug should disappear
3. Range reduction — minimize numeric values while preserving the failure

Phase 3: Simplification Pass

After removing non-essential elements, simplify what remains:

• Replace complex variable names with x, y, data
• Remove comments (they're not part of the reproduction)
• Replace complex string literals with short ones
• Ensure the minimal case runs standalone without external dependencies

Phase 4: Validation

Before declaring done:

1. Run the minimal case — confirm the bug still reproduces
2. Try removing each remaining element — if removing any element makes the bug disappear, that element is essential
3. Document why each element is necessary

Output Format

# Minimal Reproduction Report

## Original Test Case
**Size:** [N lines / N fields / N parameters]
**Bug:** [what failure occurs]

## Minimization Summary
**Iterations:** [N]
**Reduction achieved:** [original size] → [minimal size] ([X]% reduction)

## Minimal Reproduction

```[language]
// Minimal code/data that reproduces the bug
[minimized content here]

To reproduce:

[exact command to run]

Expected: [what should happen] Actual: [what happens — the bug]

Essential Elements

These elements are required — removing any one of them makes the bug disappear:

1. [element] — because [why it's essential]
2. [element] — because [why it's essential]
3. ...

Removed Elements (non-essential)

• [category]: [what was removed] — did not affect bug reproduction

Root Cause Hypothesis

The minimal reproduction suggests the bug is triggered by: [what the essential elements reveal about the bug's nature]

Next Steps

1. Debug the minimal case using other techniques (wolf-fence, root-cause)
2. Focus investigation on the interaction between essential elements
3. Test the fix against both the minimal and original cases