When you encounter a bug in your application you should never let the same bug happen again. The best way to do this is to write a unit test for the bug, see the test fail, then fix the bug and watch the test pass. This is also known as Red-Green-Refactor.
You can then reply to the bug report with "Done + Added a unit test so it can't happen again".
A test that is written after the fix, and only ever seen passing, proves very little. It might pass on the broken code too. Write the test before you touch the fix, run it, and watch it go red. If it goes green on the unfixed code, the test is not checking the bug.
// Written after the fix. Never seen red.[Fact]public void Discount_is_applied_to_bulk_orders(){var order = new Order(quantity: 100, unitPrice: 10m);Assert.Equal(900m, order.Total);}
❌ Bad example - Nobody knows whether this test would have caught the bug, because it was never run against the broken code
1. Write Discount_is_applied_to_bulk_orders2. Run it on the current code -> FAIL (Total was 1000m)3. Fix Order.Total4. Run it again -> PASS
✅ Good example - The test was red before the fix and green after, so it is tied to the bug
Once the fix is in, temporarily revert it and run the new test one more time. It should fail again, and it should fail at the same assertion as the first red run. A compile error or a broken fixture does not count, because it says nothing about whether the test can see the bug. This catches the two ways a bug-fix test quietly stops working:
Then restore the fix and note the result in the PR description, for example: "New test proven red-first, revert check confirms it fails without the fix". A reviewer can trust that sentence far more than a green tick.