We all make mistakes. But how we go about redressing those mistakes tells a lot about our personality, both our strengths as well as our shortcomings. Bugs are a natural part of software development. Testing not so much. I attribute this to, among other things, general developer laziness and the constant pressure of ‘Getting Things Done’. And there it is again – that damn word that developers, sysadmins and customers can never seem to agree upon – ‘Done’.
A bugfix without a test is an anti-fix. You heard me – right up there next to the anti-christ himself. After committing the bugfix, the developer thinks their ‘Done’ when in reality they’ve just introduced a new bug (and more complexity) into the system.
Bugs are incredibly interesting facts. They are indicative of that rare species – source code that is actually used (remember the Urban Myth that only 20% of your source code is actually used on a daily basis?). If a customer has taken the time to try and get something done with your application, the least you can do is write tests for any bugs they happened to come across. The test is your unspoken agreement with the end-user that this particular bug won’t happen again.
If we all spent an extra 10 minutes before releasing and thought about boundary cases or function interactions – but that’s another post!
bugfix - test = anti-fix (new bug!)
bugfix + test = fix
How do you handle bugfixes? Share with us below.