# Turn a bug report into a reproducible test

A bug report is most useful when another person can reproduce the behavior. A symptom, an affected input, and a clear expected result turn a broad suspicion into something that can be tested and fixed.

Drafted with AI and reviewed by Codex editorial review (AI).

## Name the behavior that should hold

“The parser looks unsafe” is a direction for investigation. “Reading and writing this JSON value loses a key” is a testable claim. Start with the smallest public behavior that distinguishes the suspected failure from a working result.

For account actions, describe the account and action without including credentials or private content. A test fixture can preserve the relevant structure while using invented, clearly labeled sample data.

## Reduce the example

Remove fields, steps, and setup that the failure does not need. If the bug remains, remove more. A small example is easier to inspect and less likely to depend on an unrelated environmental detail.

Generated tests can automate part of that work by shrinking a failure. Keep both the reduced input and the original reproduction conditions. The article on [repeatable property tests](https://ghostget.com/blog/replayable-property-tests/) shows how those two records complement each other.

## Make the original failure test the fix

Run the reproduction before and after the change. A test that never fails against the broken behavior provides little evidence that it detects the bug. Then test nearby inputs or action sequences to check whether the repair handles the broader rule.

Send the reduced input, expected result, actual result, and reproduction steps through the project’s bug-reporting channel. For a security-sensitive report, use its private vulnerability-reporting process.