Feed on
Posts
Comments

We’ve seen the first two ways that TDD does its bizarre trick of increasing production by adding more code: TDD reduces mental scope, and it multiplies developer intention.

I struggled for a while to come up with the right words for this one. Of all the magic, this is the one that almost everyone can understand, and almost everyone can at the same time underestimate its importance.

What Does “I Programmed All Day” Mean?

I asked that question here, and my answer looked more or less like this: I …

  • typed in some code;
  • drew some pictures;
  • rigged up the debugger;
  • ran the debugger;
  • waited for the debugger;
  • figured out how to set the breakpoint so I got the failure case;
  • debugged an execution path for a while that wasn’t actually broken;
  • accidentally stepped over the line of code instead of into it, *nine* times;
  • read 50 times more code than I wrote;
  • asked peers to look at a problem;
  • got asked by peers to look at a problem;
  • stared into space;
  • threw some kind of something at other people;
  • surfed the web looking for answers;
  • surfed the web looking for cool pictures;
  • and so on…

Do you see those six sentences in the middle that mention debugging? Uh-huh.

Debugging Is Expensive

It doesn’t really matter whether you are debugging via the most sophisticated of hardware board-testers, or you’re just using printf statements. (Oh, I should add “put print statements in a bunch of weird places to see if I was even triggering the execution path I thought I was.” I do that a lot. Don’t lie to me.)

Either way, it’s a tremendous amount of time spent on not doing the right stuff, I mean the stuff to exercise the bug, find it, and fix it.

Microtests Short-Circuit The Old Debugging Process

Microtests change debugging, in two different ways.

First, some of them go red when you thought what you were doing was safe/right. Having a bunch of microtests is like having a debugger that’s always on.

Second, they are a great way to capture the repeatability of a bug. If you find a defect, and you’re doing TDD, the first thing you do is write a microtest that exercises the defect. From that point forward, you’ll know exactly what to do to exercise the problem: run your tests.

Together, these two changes will soon enough have you making the TDD pledge: “I will feel mildly guilty about launching the debugger when I was programming.”

Part of TDD’s Magic Is That
TDD Directs Debugs

One Response to “How TDD Works Its Magic (3): Directing Debugs”

  1. Anonymous says:

    Lately i am finding that “put print statements in a bunch of weird places to see if I was even triggering the execution path I thought I was.” works really well for debugging actually; usually to find the right breakpoint to set.

    re: “accidentally stepped over the line of code instead of into it, *nine* times”

    *9* times! you are truly a master. I usually accidentally step over the line of code 15 or more times *sigh* i have so much to learn *shakes head in shame*

Leave a Reply

AWSOM Powered