Unit tests and debuggers

I once took some heat on a Test Driven Development (TDD) forum for suggesting that, as a rule and if possible, it’s a good practice to step through a new or updated method in the debugger.  I was told that if you had unit tests, there was no need for a debugger, end of story.

No knock on TDD, but that assertion is patently absurd. When I step through my code, I confess that it is not at all rare to be surprised at how the code is actually working.

A passing unit test will not necessarily alert you about resources that you should have freed but have not.  It’s doubtful that the test will point out that you are re-initializing state: perhaps resorting a static list or executing other set-code that only needs to be performed at start-up.  It won’t tell you that you keep iterating through a loop after you have found the item you are searching for, rather than just returning the result.  A unit test won’t tell you that you are performing a linear search when you could use a hash table, while walking through such a search in the debugger could make this painfully obvious.

I hope those examples do not seem too contrived, and I hope they illustrate that there  are potential benefits to checking your code with a debugger, if that is possible.  (Admittedly, sometimes that’s hard to manage: near real-time systems handling large amounts of data; distributed systems with time-outs that are short for humans to manage, languages without source debuggers, and so on.)

And make no mistake, I am absolutely in favor of automated unit tests and other regression tests.  It’s too hard to sleep at night if you have to make code changes without having a decent test suite.  In fact, to come full circle, unit tests are often great spots in the code for checking with the debugger.

But for me, the deeper and troubling issue than a debate about debuggers is how software methodologies (along with languages, operating systems, and tools) develop devotees rather than practitioners.  It makes me wonder if there is some prevalent trait among people drawn to coding that makes them more likely to abandon critical reflection, more ready to drink the Kool-Aid, whatever the flavor de jour may be.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s