Using asserts to help find bugs in OneNote
Of the many different types of bugs testers find in products, "asserts" seem to be the most obvious. Vastly simplified, an "assert" is a piece of code that checks for some unexpexted condition before continuing, and pops up a dialog if those conditions are not met. A simple example would be checking for a denominator of zero before dividing, and in C# the code would look something like this:
double numerator = 1;
#if DEBUG
{
Assert (denominator !=0)
MessageBox.Show("denominator = 0");
//skip the rest of the code
}
#endif
double result = numerator / denominator;
The #if DEBUG tells the compiler to only add this section of code if a debug build is being compiled. Debug builds have a lot of this type of code in them, and are used for internal use only - they run much slower than builds we ship that they are useful only for troubleshooting and because they include so much error checking, are much larger file-size wise. And you can imagine how annoying it is to have pop ups interrupting your work flow.
The Assert command works like English: "I assert the following statement is true: the value of the denominator is not zero." If that statement is true, the code continues to run. If it is not true, then I know I am in an unexpected state, and need to find out why before trying to continue running the code.
So what happens, if you are running a debug build, is that the code in the #if statement gets compiled and executed. In this case, the denominator value may be zero, so the system will pop up a message box to let me know we are in an error state, and break out of the code before trying to divide by zero. This would be more useful if the value of denominator were set somewhere else - for instance, if some other function had called this divide function and passed in a zero value of a denominator, the assert will point out the error before trying to divide by zero. When debugging the code, I can more easily tell that I am in an error state. How I got into the error state may still be a mystery, but at least I have a starting point.
(Purists can point out that I really could use an "if" statement to check for a zero denominator and avoid the Assert functionality, but I'm trying to keep it simple with this example).
Another use for the #if DEBUG statement can be seen in my table sums addin. I have a statement that opens a pop up message immediately after the toolbar button is clicked, but only in debug builds. This made it easier to attach a debugger to a running process, and let me step through my code as I was troubleshooting. The version of the addin I released, though, was the Ship version, and the compiler ignored those three lines.
So bugs that we enter regarding asserts are usually pretty simple:
Click the button I'm testing for this made up test
Point to a zero byte file
Click OK
Result: Assert fires: "File size is zero bytes!"
And the expectation in this case is that since zero byte files are allowed to exist, we need to take that into account in whatever routine is being called from step 2.
There is much more to be said about asserts. This just scratches the surface...
Questions, comments, concerns and criticisms always welcome,
John