My current project is nearing its release date after months of paring down the bug list, so I was somewhat alarmed this morning when I fired up Outlook and found a bunch of early morning bug reports from the latest build. Panicky bug reports. Reports of message boxes popping up left and right, full of scary looking technical jargon. “What did you guys to the latest release?” they cried? “Don’t you test these things?”
Well, actually, we do test these things, and those scary message boxes were a direct result of how we test things. The guy who did the build had forgotten to switch Visual Studio’s Build settings from Debug to Release, so all the “Debug.Assert” messages that we use to warn coders about possible bugs were now menacing our internal users. (Well, actually they’re supposed to be “testers”, but that doesn’t stop them from bleating in alarm at any error message that pops up on the screen.)
Why so many Asserts? Why not a more subtle way of reporting test results, like a log file? We do use log files, and our testers/users send these log files with their bug reports. I’ve turned on logging on my own development PC as well, of course, but logging is nowhere near as useful. The Assert has the advantage of being a) an attention grabber, and b) an opportunity to use the debugger to see exactly what’s going on at the point that the Assert fails. As a coder I’m embarrassed to admit that even my attention needs to be grabbed, but some bugs just aren’t apparent from what happens on the screen.
I use Debug.Asserts in every Exception handler (natch), but also as a way of “defensive coding”. Almost any time an object is passed as a parameter or read from a data source, I use an Assert to confirm that it’s what I expected it to be: not null, within limits, and of the same size as corresponding lists and arrays. This practice has a collateral effect on my coding style, since thinking about everything that could go wrong ensures that I write code to gracefully handle these “unexpected” error conditions.
But again, why did so many Debug.Asserts pop up today, in a product that has most of the bugs shaken out of it? As it turns out, these particular Asserts called attention to some previously unreported bugs — bugs that resulted from differences between the data used by the testers and the coders, or by different habits that the groups developed when navigating through the user interface. Without the Asserts, the users wouldn’t necessarily notice that a cell or two were incorrect in a grid, and they wouldn’t bother to report that they occasionally had to click on a field a couple of times in order to give it focus. The scary message boxes this morning ensured that these subtle problems were finally reported.
Naturally, when I realized what had happened this morning we immediately released a new build with the Debug features turned off. But I’m tempted to “accidentally” release a Debug build from time to time in the future, just to make sure that the small bugs get reported.
