Testing and Debugging

In this, the second follow-up post to my previous posting about a small project at work, I’m discussing issues that came up in testing and debugging.

First, click back on that older post (here).  That’s okay; I’ll wait.

Okay, done? 

Now, did you catch my problem?  I didn’t until I ran against a specific scenario.  What happens when there’s a blank line?  In the case of my code, I got caught being too clever.  I tried to edit out blank lines.  My problem is that I added a “break;” when blank line was found.  That made my “while” loop think it was done, and then left off anything after the blank line in that file.

Oops.

Then, I discovered something else.  A requirement I had interpreted as “sometimes there will be blank lines” was actually, “Sometimes, in an otherwise populated line, you’ll receive UNIX nulls.”  That’ll break a StreamReader.  If someone knows a way to handle those in a StreamReader, I’d appreciate an email.  However, I don’t know such a way, and so decided the best thing to do was just copy the bytes over.  Then, since I’d be working with bytes, it wouldn’t matter if it was the UNIX byte that said “null,” it’s still a byte and would get copied over.

Looking for a way to do this, I turned to the ultimate in developer help: StackOverflow.com.  Once there, I discovered, once again, that Jon Skeet is awesome.  I’m not posting his code, since I mostly just added Exception Handling, and changed names so they fit my solution better, and basically used his code.

So, how did I discover these problems:  Testing and Debugging.  I know it’s a long way to have gotten to what is supposed to be the point of the post, but I wanted to show how much pain it saved me, since I would have pushed to production based on the fact I knew my code “functioned as designed.”  The problem is that it would have been designed wrong.

Using the VS testing functionality (my client is on VS2005 btw), however, wasn’t enough.  You see, my test passed when I ran it.  However, I believe whole heartedly in having actual output that I can verify.  Again, my code functioned as designed.  It wasn’t until I opened up the test output that I found my problems with those blank lines.

So, three quick things about Testing your code:

1) Always Unit Test your code.  Once I started making changes, I did start failing my Unit Test.  If I’d only checked my output, I might not ever have known there were additional problems.

2) Set up Unit Tests which will test your assumptions as well as the code itself.  I could have used only files with complete data in them to test, and I would never have found my issues at all.

3) Always provide yourself actual, verifiable output, whenever possible.  If I hadn’t done just that, I would never have known about my problem at all.