Testing is the New Debugging
I've gradually noticed that developers don't use debuggers much any more. It was a gradual sort of thing, even in my own occasional development activities. This got me to thinking about the shift we've experienced over the last several years to managed platforms, primarily Java and Microsoft .NET. They have changed a lot of behaviors, because most bugs in the past typically had something to do with memory allocations, references, and de-allocations.
(Of course, some of you might remember programming for DOS, when you also had to worry about small, medium, and large memory models, adding yet another layer of complexity to using and misusing memory).
Ten years ago, I spent possibly as much as half of my development time chasing down memory references. Today, I do occasionally think about the implications of my implementations on memory use, but I know things are going to work.
But even when they don't, I don't typically turn to a debugger. The debugger menu selection on my IDE remains ignored, even when I have problems getting something to work correctly. The debugger—which lets me set breakpoints, step through code line by line, and examine the value of variables—seems more and more like a sledgehammer attacking a thumbtack problem.
Instead, once I get something running, I'll write a quick unit test, and see what results it returns. From there, I might record code coverage to identify the code path used, and write a few more tests to narrow down the possible scope of the error. As a last resort, I might turn to the debugger to step through the code executed by a unit test to examine specific pieces of logic.
It's not that bugs have gone away with managed platforms. Instead, I've come to the conclusion that the debugger is simply less useful when the majority of your problems are logic errors, failure to consider a wide range of possible use cases, and flow-of-control errors. It's more useful to localize the error with small tests, collect information during these tests, and then drill down into that information to understand not only the error, but what led to it.
That is why I say that testing is the new debugging. The corollary of that is that any way to improve the process of writing and executing tests, evaluating the results, and collecting more detailed information during testing to enable the drill-down is an essential part of finding and diagnosing errors. There is still a role for traditional debugging, but it should take a back seat to an increased focus on testing. Managed platforms made a lot of coding practices more efficient, and testing can make debugging more efficient as well.
I talk about this topic in more detail in my column in the November issue of Java Pro.
Posted by Peter Varhol on 09/17/2004