Protocol
Shrink the example until the same failure is hard to hide
A thousand-line attachment is evidence. A six-line reproducer is an invitation to solve the problem.
When it fits
- A large file, message or sequence fails, but nobody knows which part matters.
When to avoid it
- Do this in an isolated test environment. Intermittent failures need repeatability work first; smallest-looking is not the same as globally minimal.
Why it matters
Reduce the input without changing the failure you are investigating. Remove a chunk, rerun the same check and keep the smaller input only when the original failure remains. When large cuts stop working, try smaller ones.
Steps
- Freeze a safe copy, the environment and an exact failure signature.
- Remove one chunk; distinguish the original failure from an unrelated validation error.
- Save the reduced failing case and a nearby passing case.
An example
A text import fails with hundreds of lines. Reduction leaves two lines and a separator; deleting that separator makes the same test pass.
Check your result
Another person can reproduce the specified failure with the reduced input.
Keep this limit in mind
- Do this in an isolated test environment. Intermittent failures need repeatability work first; smallest-looking is not the same as globally minimal.
Connected ideas
Useful withBisect the version history instead of inspecting every change
Evidence and sources
Supports
Delta debugging removes parts of an input while preserving a specified failure; a 1-minimal result need not be globally smallest.
The practical reduction loop assumes a meaningful, sufficiently repeatable test and preserves the original failure signature.
Reducing Failure-Inducing Inputs · Delta Debugging; 1-minimality discussion