Andrew Stopford's Weblog

tests in code aren't the documentation how the code works internally. Some people seem to think that, but they just test the outer interface's behavior.

(here, interface is the broader definition of the word).

Furthermore, the debugger isn't a code reviewing toolkit. It's also not equivalent with debugging. A debugger is a tool used DURING debugging, but you can also debug without a debugger, you're then still debugging. Unittests don't make debugging time smaller, they just test the code written. I.o.w.: they are measures to see if what's written is correct, but if that's not the case (test fails) they can't tell you WHERE the cause of that is and WHY, they just tell you that something is wrong.

Solving that is a puzzle. Most of the time, you don't need a debugger at all, just common sense.

So, what you tried to tell with the post, I have no idea... perhaps you wanted to illustrate that writing tests is making your code more robust. I can agree with that, but that has nothing to do with debugging, using a debugger or understanding how code works. In libraries with hundreds of classes and a lot of code, you can stare at your unittests all day, but you still won't understand how it works INTERNALLY.

That's something that shouldn't be overlooked, i.e.: documenting how stuff works internally is still required, no matter how much unittests you write.

For many developers, the current infatuation with unit testing has taken a bad turn, in my opinion. A colleague of mine recently attended a week long seminar taught by a somewhat famous coding guru. I won’t say who the instructor was for fear of embarrassing him in a few years when he understands the folly of his youth. My colleague came back to work bragging that “So-and-so hasn’t used a debugger in 3 years because his unit testing discipline is so strong. I’m never going to use a debugger again.” Wow! I didn't have the heart to tell my co-worker that the lecturer had been teaching full time over the past 3 years which explained why he could make such an outrageous statement.

That same co-worker came to me a week later with a seemingly difficult problem he had been trying to solve for hours. He was out of options or so he thought. I listened to his problem and said, “Let’s run your code in the debugger to see what it’s doing.” He stood idly by while I fired up the debugger. Within one minute, I had found the root cause of the problem. The problem was very simple and the debugger exposed it brilliantly. On exception, some of the code my friend was depending on was throwing a new exception without attaching the old exception as the InnerException. The debugger let me inspect what was happening and to SEE the real root cause.

In this case, even the finest unit tests in the world wouldn’t have uncovered the real problem. My friend’s tests uncovered THAT there was a problem but they could never have found the root cause given that the code was hiding it. My advice is to use debuggers for what they are good for and to use unit tests for what they are good for. Furthermore, while unit tests are good for setting expectations about what code should and shouldn’t do, they depend heavily on the developer’s understanding of the boundary conditions. When working with complex business logic, the perimeter of understanding is often limited by many factors which are beyond the developer’s control. It’s very good to unit test prolifically. It’s better to use it with an arsenal of tools including debugging, profiling, functional automation, object mocking, etc.

What’s baffling about this current generation of developers is that they claim to embrace the open source movement. I know I do because I truly love using the debugger to step through the source code for Spring.NET, NHibernate, log4net, NAnt and so many other brilliant bodies of work. Stepping through a factory pattern implementation in Spring.NET, for example, is often like drinking from a fire hydrant of knowledge. And once in a while I’ll stumble on something in the code that I know could be done with much more efficiency. So, I’ll pop out of the debugger and pop into my profiler to confirm my suspicions. Then I’ll extend a class or two and pop back in to EACH AND EVERY ONE of my tools make sure everything is just as I expect it to be. Voila! The code runs 8 times faster under heavy load and I have much more confidence because I've actually SEEN IT working inside and out.

What I don’t understand, to be honest, is that if developers love free source code so much, why are so many of them afraid to step through it as it’s running? If developers are not going to use the debugger as part of their learning ritual (or at a minimum, for faster triage), why do they need the source code at all?

Pingback from  at what time did you come today