Talk:Delta debugging

Suggestions

 * Refocus and rename the article to "Automated test-case reduction":
 * The term "Delta debugging" is sometimes used as a synonym, but can also refer to a broader methodology (Zeller's original use) or to only the original reduction algorithm (without asymptotic optimizations or grammar-awareness)
 * Add a short section titled "Significance" near the top:
 * If the original fault-inducing input is from fuzz testing, reduction can help by removing red herrings.
 * If the original fault-inducing input is closed source, reduction can help to create a smaller version that the author is comfortable sharing with the compiler team.
 * A simple testcase makes it easier to determine the cause of the bug and identify duplicates.
 * A simple testcase can be added to a test suite as a regression test with confidence that it will continue to test the same thing / require minimal maintenance.
 * Limitations
 * The fault must be reproducible &mdash; For nondeterministic crashes, it often helps to run under a tool that explicitly catches undefined behavior such as a code sanitizer or memory debugger
 * Risk of reducing to a different bug &mdash; you might want to retest the original to make sure you fixed the right bug.
 * Reduction is not always simplification &mdash; a naïve reducer may introduce other errors (such as missing closing tags in HTML) which aren't relevant for reproducing the bug
 * Convert the list of tools into a comparison table with columns:
 * License
 * Language
 * Interestingness-test specification
 * Strengths (e.g. Perses can leverage a supplied grammar, C-Reduce works on anything with a vaguely C-like syntax, rust-reduce works across multiple files and applies Rust-specific transformations)

CoI notes: I am the original author of a reducer called Lithium. I've been involved with some of the projects that might serve as examples or sources, including Mozilla and Rust. Jruderman (talk) 23:20, 26 June 2024 (UTC)