June 29, 2011
I must admit, I probably didn’t test my code as thoroughly as I ought to have. Let me re-phrase that. I did test it. I just didn’t write complete test cases to ensure regressions weren’t introduced when new bits were added. As a result, maintenance always took longer than it should have, and bugs were introduced when changes were made. Even though I had read and studied the importance of testing very early in my software development career, it was only after continued frustration with things breaking that I got off my butt and actually started using testing practices like TDD, BDD and even writing tests for code that had already been written. I made it a goal to have the code as covered as possible.
Initially it took way longer to write code. Way, way, way longer. I did get frustrated. I questioned if this was really the way to go. But in the end, I got quicker at writing tests. I more often than not wrote the tests first. And things were good. If things broke, I wrote a test, fixed the bug, tested the entire app to ensure I didn’t break anything else. And things were good. I’m now very much an advocate for testing and consider it probably the most important skill in my software development bag.
I recommend reading the post by Ryan Bigg. It covers some other points in relation to testing, especially the economic and financial implications both personally and to an organisation when testing is not a priority.