Tips » Application Code Quality » Five Tips for Catching ALL of the Bugs in Your Code

Five Tips for Catching ALL of the Bugs in Your Code

by Don Jones

Bugs and performance: The two things any end user can recognize as "poor application quality." So how do you go about catching all of the bugs?

Unit Test. This one's obvious, and you probably already thought of it. Test your code! Test it as you write it, then test nightly builds of the complete application. The problem here is that unit testing alone actually tends to catch relatively few bugs, although the time you spend unit testing could be much more productive in terms of bug squashing.

Use quality test data. Everyone likes to harp about production-quality test data when they're doing formal testing, but what about in unit testing? The fact is that a formal integration test is your last chance to catch bugs, and I personally like to catch as many as possible in unit testing. It's impossible to catch them all of course, but I regard every bug that comes back from a formal test cycle as a kind of personal failure, so I try to aim for a perfect score. One way to do that is to use production-class test data during unit testing. That way I'm not just banging in "asdfasdfasdf" for customer names; I'm getting names like "O'Brien" that might trigger a bug of some kind.

Test every code path. This can be really tricky. After all, how many conditional statements and loops does your code have? It can be difficult to remember every single scenario that will trigger every possible code path. However, code quality tools can not only help identify and catalog code paths, they can "watch" you unit test and keep track of which paths you've tested. Afterwards, you can look at the untested paths, figure out what conditions will trigger them, and run through any necessary unit tests to exercise those bits of code. At the same time, this can help you document all those scenarios and conditions, so that later, formal, automated testing suites can do a better job of catching every condition during nightly build testing.

Test in variety. Make sure you're running at least major unit tests in every operating system (OS) where your application will be deployed. The magic of virtualization makes this much easier than in the past; now, each developer can conveniently have a Windows XP computer, a Windows Vista computer, and a Windows 7 computer, all running on their development workstation or in a data center-housed virtualization host. I'm shocked at the number of "new" bugs I come across when I move code to an older or newer OS; typically, fixing those bugs helps educate me so that I can avoid bug-causing situations as I continue coding new parts of the application.

Use bad test data . The biggest problem I have in finding bugs is that I don't try all the goofy stuff a user will try. Sometimes, I'll enlist an end user to come over and run through a unit test on new code. I'll use a utility such as Camtasia ( www.camtasia.com ) to record what they do, then review the results. This helps educate me about what users will try that I wasn't expecting; I use that as further input to unit tests and call it "(deliberately) bad test data." Doing this reminds me to enter dates where numbers were unexpected, enter names that are longer than the corresponding database fields, and so on. These "boundary tests," if you will, help make sure my data validation code is tight, and helps uncover situations that users will probably run into every day that I had never imagined.

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.