Unit Testing V. The Debugger

From a recent presentation I delivered, it finally hit me that the craft of debugging is really a form of manual unit testing. Yes, this may be a "duh!", but this was an "ah hah!" moment for me.

Think about it.

You compile your application and start it in the debugger. You then click, select, submit, type and probably click your way to the part of the code you want to make visual assertions on. You'll use watch windows and breakpoints so you can inspect the outcome. You then repeat this until the code is doing what you expect.

This is synonymous with:

1) instantiate the test subject (probably a class).
2) establish its initial state.
3) call a method on it.
4) use Assert()ions to determine if the outcome is the expected one.
5) repeat

Interestingly enough, it takes FAR longer to compile (integrate), run the debugger (instantiate and set up initial state), then make the Assert()ions (watch window, breakpoints and immediate window) then repeat the process. Also, you are human and therefore are subject to all sorts of distractions that minimize the probability of executing the same code path every time. This results in poor testing and invariably less than satisfactory code quality. Add 5 scenarios you need to test for the chance of screwing up is greatly exacerbated.

Unit tests, on the other hand, are repeatable, not subject to human distraction, do not require full integration of the application and can be shared with your team.

You'll find, if you're new to Scrum, that unit testing will save you a ton of time and give you a much better chance of burning down to zero instead of burning out.

If you're interested, let me know and I'll be happy to share my recent Unit Testing 101 slide deck with you as well as sample code (.NET) that demonstrates the basics as well as advanced concepts using a great addition to the Mocking world known as "Moq" (Mock You).

Learning from our elders

Over the past 5 years, I've come to the conclusion that there is something missing in the first few years of training aspiring developers embrace when they feel the pull towards software development as a career.

Scrum and XP practices have been around for quite some time now, 10 years or more to be more precise than "quite some time now".

I believe it's time for those of us who are more or less .NETters to take a break, reflect and start looking to our SUNners across the aisle (or Oraclers). Almost every tool we use in the .NET world to assess code quality got its start with a "j" in its name or at least with the absence of an "n". This tells me that there are either more mature experienced developers who are writing or have written applications in Java from which I can learn. The alternative is that we in the Microsoft camp write flawless code and therefore do not need to lean on quality tools.

I can tell you that I personally don't write flawless code. I lean heavily on quality tools to tell me when I'm an idiot. The beauty of those tools is they typically report my idiocy only to me and not to the people who assign my bonus. Of course, when I'm a real idiot and don't ask my quality tools if I'm being one, they will also quickly report to everyone that Tim had a poor thought moment.

Many of us pour libations out to Uncle Bob and Steve McConnell while others are clueless who these guys are and why we should care about what they say.

Here's an interesting factoid. From McConnell's Code Complete 2 book, he states that "a study conducted by IBM indicated that for every hour spent doing code inspections, 33 hours of additional work was saved".

These guys have been around the block a few times. We as developers should understand that their experiences can become our experiences if we only take a moment and listen (or read).