DEBUGGING

Prev don't be afraid of buying books Next

DEBUGGING We didn't talk about the time we spent laboriously single-stepping through our code searching for bugs. Or about painstakingly poking through data structures looking for that bad value. We didn't talk about it because we didn't do it. The write-up of the project reflects exactly what happened, down to each line of code we wrote. We did omit most of the times we ran the tests... because we did it constantly (and painlessly). We ran the tests after every change, after every compile. And many times just to be sure. So... what about the debugger? Well, honestly, we never used it. I was telling someone about Eclipse and they asked what the debugger was like. After a moment of thought, I said something like, "Pretty good...I guess...I haven't used it more than a couple times...and that was mainly out of curiosity." I'd been using Eclipse almost daily for over a year at that point. He couldn't believe it. So what's going on here? Well, once you get good at TDD you don't have much use for a debugger. This is because you are working in very small increments, adding very little code at a time. You write a test, then write just enough code to make it pass. Once it passes, you're done with that chunk of work. When you're refactoring, you start with all the tests passing. After each small change you rerun the tests (likely, a localized subset of the entire suite). If they don't all pass, the problem is in that last little change you made. Because your tests are watching your code for bugs in such tiny increments, you never have much trouble finding a bug. It's hard to believe how well this works until you try it yourself. Even if you were feeling brave (or foolhardy) and made a big change between tests, you simply back that change out and go through it again in smaller steps. . . running the tests after each step. (This is a common and humbling lesson when you are first learning TDD.) So, yes, TDD sounds like a lot of extra work upfront (as my friend above commented), and certainly it is more work upfront than many of us are accustomed to. But it actually saves much more work on the backend (debugging) than it costs upfront. As nonintuitive as it may be, TDD saves you time. You'll find that once you acquire the feel for it, you'll work much faster than when you were using the code and debug approach. And you don't have to wait weeks to discover this higher speed: it will be obvious after just a few hours, and certainly after a couple of days. You just won't be spending all that backend time sleuthing for bugs. You'll be making rapid, steady, bug-free progress, task after task. As I keep saying, you will find it exhilarating.

	Amazon