Assessing a unit test written after a bug is fixed

When fixing bugs I usually try to reproduce the bug with a failing unit test before fixing it, assuming the bug is within some code that can be covered by unit tests. However, occasionally I implement the fix before a test is in place, usually when I’m initially not confident enough in my understanding of the problem to be able to reproduce it with a unit test.

I still add a unit test afterwards where possible, but of course this does leave the problem that the test passes. If I’ve never seen it fail, how can I know that the test is actually fit for purpose, and would fail if the bug is re-introduced?

My go-to solution in this scenario is to revert the git commit which contains the bug fix, but without committing the code. This keeps the code history clean, but also gives me confidence that all my changes are reverted. I can then run the tests again, ensure everything fails with the expected failure messages, and discard my changes knowing that the committed fix is working.

The command for this is a simple one:

git revert --no-commit <commit-hash-containing-bug-fix>