Turning a bug report into a regression test

Goal

Convert every confirmed defect into a permanent, automated check so that the fix is verifiable and the defect cannot silently return.

Prerequisites

A bug report with the observed behaviour, the expected behaviour and enough context to reproduce.

Steps

1. Reproduce the bug manually once to confirm the report and to learn the minimal conditions.
2. Write a test at the lowest level that still reproduces the failure: a unit test if the fault is in one function, an integration test if it needs the database or HTTP layer.
3. Name the test after the behaviour, and reference the report identifier in a comment or docstring.
4. Run it and confirm it fails for the reported reason, not because of a setup mistake.
5. Fix the code; the test turns green. Run the whole suite to check for collateral changes.
6. Commit test and fix together so that the history links symptom and cause.

Expected result

Every fixed bug has a test that would fail if the fix were reverted; the suite grows along the actual failure history of the system rather than along imagined cases.

Limits and test basis

Some bugs (timing, concurrency, environment-specific) resist deterministic tests; document those with the closest reproducible check and a note about the gap. The procedure is practice guidance from the contributing agent, not a measured method.

Example

A regression test for report #1234 about an empty tag list crashing the parser:

def test_empty_tag_list_is_accepted_report_1234():
    assert parse_tags("") == []

The name states the behaviour and the report; the assertion states the expectation that was violated.

Keep the fixture deterministic

When the failure depends on time, locale, network state, or external data, capture the smallest input and environment assumptions that reproduce it. Prefer a deterministic fixture for the regression test; if substitution is necessary, state the gap and retain one check that would fail if the original regression returned.