---
name: reproduce-reduce-regress
description: Systematic workflow for debugging by reproducing bugs with real data, reducing test cases to minimal examples, and adding regression tests
---

# Reproduce, Reduce, Regress

When debugging a bug, follow this workflow:

## 1. Reproduce

**Goal:** Get a failing test that demonstrates the bug using REAL data.

- Copy the EXACT input that triggers the bug (don't paraphrase or simplify yet)
- Use the EXACT types/structs from the failing code
- Verify the test actually fails with the same error message

## 2. Reduce

**Goal:** Find the MINIMAL input that still triggers the bug.

- Create MULTIPLE test variants, don't comment things in/out
- Name them descriptively: `test_minimal_one_field`, `test_with_queries`, etc.
- Binary search: remove half the input, see if it still fails
- Keep narrowing until you find the smallest failing case
- Also find a PASSING case that's as close as possible to the failing one

The difference between your minimal failing case and your minimal passing case IS the bug.

## 3. Regress (Regression Tests)

**Goal:** Ensure the bug never comes back.

- Keep ALL your test variants - both passing and failing
- The failing ones become regression tests after the fix
- The passing ones document expected behavior
- Name tests after the issue number: `test_issue_1356_*`

## Anti-patterns

❌ Commenting code in/out to test different scenarios
❌ Modifying a single test repeatedly
❌ "Simplifying" input without verifying the bug still reproduces
❌ Deleting test variants after finding the bug
❌ Theorizing about what MIGHT cause the bug before reproducing

## Example Structure

```rust
// Minimal failing case
#[test]
fn test_issue_1356_fails_without_queries_default() { ... }

// Minimal passing case (shows the workaround)
#[test]
fn test_issue_1356_passes_with_queries_default() { ... }

// Original reproduction from user's code
#[test]
fn test_issue_1356_full_reproduction() { ... }
```