This accurately catches the reasoning behind my approach to testing though. When you fix a bug, write a test that reproduces the bug first. That way, when someone tries to refactor the messy code, they'll know that they broke something that was causing a real big.
I generally try to have two type of test: nominal "happy case" tests that verify basic functionality of modules when used in a normal way, and bug fix tests that are labelled as such, with a reference to the bug in the bug tracking system. So now when you see my warty code and try to clean it, the test fails, and you can even find a description of the original problem that the warty code addresses. Now you know that you either have to find a cleaner solution, or just leave the warty code alone.
This system means that most of the tests I write are targeted at things that really cause bugs, not just busy-work testing of things that would never go wrong, but rigidify code bases (the more tests you have, the more you have to modify when refactoring, and how do you know if the test or the code is wrong during the refactor???)
I generally try to have two type of test: nominal "happy case" tests that verify basic functionality of modules when used in a normal way, and bug fix tests that are labelled as such, with a reference to the bug in the bug tracking system. So now when you see my warty code and try to clean it, the test fails, and you can even find a description of the original problem that the warty code addresses. Now you know that you either have to find a cleaner solution, or just leave the warty code alone.
This system means that most of the tests I write are targeted at things that really cause bugs, not just busy-work testing of things that would never go wrong, but rigidify code bases (the more tests you have, the more you have to modify when refactoring, and how do you know if the test or the code is wrong during the refactor???)