My favorite reason to write unit or integration tests for bug fixes is that it forces you to understand, triangulate and formulate the problem. I have had to work with so many bug reports that are vague: it doesn't specify how to replicate the issue and what's the expected behavior.
When you write a test before fixing it, you can confirm that you have found the bug (test fails), that you have fixed it (test passes) and there's something for peer review to look into to better understand what happens and if there are some edge cases that you didn't think about.
A great book on the topic, especially with legacy code is Michael Feathers's Working Effectively with Legacy Code. I've learned so many good tricks and habits from that book that have helped me tackle some bloated 15+ years old codebases. edit Ah, just noticed Franz had already recommended the book below.
My favorite reason to write unit or integration tests for bug fixes is that it forces you to understand, triangulate and formulate the problem. I have had to work with so many bug reports that are vague: it doesn't specify how to replicate the issue and what's the expected behavior.
When you write a test before fixing it, you can confirm that you have found the bug (test fails), that you have fixed it (test passes) and there's something for peer review to look into to better understand what happens and if there are some edge cases that you didn't think about.
A great book on the topic, especially with legacy code is Michael Feathers's Working Effectively with Legacy Code. I've learned so many good tricks and habits from that book that have helped me tackle some bloated 15+ years old codebases. edit Ah, just noticed Franz had already recommended the book below.
Thank you very much, your feedback is gold! I definitively will purchase this book, seems a must have according to your experiences folks :)