25. August 2008 09:41
Grad school just started back for me today, so this is going to be a short post. Hopefully I'll still be able to do three (hopefully high-quality) posts a week once things stabilize.
I ran into an issue today where one of the systems that I maintain at my day job had been rendered completely unusable by a series of code changes that had been committed over the last month. The particular system in question is mostly a web forms app, so it's a bit difficult to unit test and therefore has very low test coverage. Because of that, it falls to the developer making changes to thoroughly test things manually in most cases. Today, it became evident that this unwritten rule of testing was no longer being followed AT ALL. In one case, the code modifications sort-of worked. It's conceivable that the developer making the changes tested them, but failed to test thoroughly enough to notice that he completely broke the vast majority of the existing functionality for a particular operation. In another case, the code modifications didn't work. Period. If you tried to view the page, you were greeted with a NullReferenceException. It didn't matter how you navigated to the page or what the environment was, there was no possible way the code was ever going to work. That means the developer didn't even bother to load the modified page up in his browser.
The result of these gaps in testing is a lot of pain and frustration for me personally, and wasted money for the company. I had to roll back an entire month of new features and changes to get to a stable build. That means our testers won't have as much time to test new features, and it means that someone now has to go back and repair all the things that were broken. And it means that a 15 minute deployment took me three infuriating hours instead.
The morale of this story is: if you make a code change, no matter how seemingly minor, be DAMN sure you test it. If you absolutely positively can't write a unit test for it, be sure you do very, very thorough manual testing. Don't just fire-and-commit and assume it all works, because it probably doesn't. As far as I'm concerned, if you can't prove that it works, it doesn't work, end of story. If you can't test it, don't commit it. Ask a more senior developer for advice instead.
About Matt Honeycutt...
Matt Honeycutt is a software architect specializing in ASP.NET web applications, particularly ASP.NET MVC. He has over a decade of experience in building (and testing!) web applications.
He’s an avid practitioner of Test-Driven Development, creating both the SpecsFor and SpecsFor.Mvc frameworks.
He's also an author for Pluralsight,
where he publishes courses on everything from web applications to testing!