From: Bill Kelly <billk@...>
Date: 2006-05-08T14:01:18+09:00
Subject: Re: A major ruby annoyance!

From: "Roy Sutton" <roys@mindspring.com>
>
> Unit testing certainly can point out there -is- an error.  The 
> fix he proposes for his problem (typoing variable names) tells him 
> -where- the problem is.  Unit tests can tell you generally where you 
> problem is but it still takes the debugging work to step in and find out 
> what -caused- the problem.

Hi,

I'm not sure how many people might know about this (or
how many might care <grin>) but: The state of the art in
Test Driven Development has come pretty far.  Drop by a
TDD mailing list and ask folks how many minutes a year
they spend stepping through code anymore; or indeed, if
they even use a debugger at all.

Most TDD folk are likely to say they use a debugger rarely,
if ever.  Maybe to deal with weird interactions with a 
third party module to which they don't have tests.  But on
the TDD codebase?  I rarely if ever use a debugger in my C++
TDD code and never in Ruby, nor do I miss it.

Stepping through code in the debugger is inefficient
because it doesn't buy any security for the future.  The
debugger is a great tool when needed--this is definitely
not some anti-debugger rant--but the key difference of
unit tests is that, once written, they are _automated_
tests, where using the debugger is a wholly manual
process each time.

State-of-the-art TDD uses One Button Testing(*) where
you bind a key in your editor to run your tests, and
without interrupting your flow.  You get to keep coding,
while your tests are running, but if the tests don't
pass, you get results that allow you to easily navigate
to the failure point.  If you're running your tests
frequently, chances are the failure relates to code you
just typed moments ago.

(*) Hmm - I see I'm behind the times.  Some folks were
already pushing toward Zero Button Testing three years
ago. :)
http://www.testdriven.com/modules/newbb/viewtopic.php?topic_id=412&forum=6

Well anyway: I'd been programming for about 18 years
before I first tried TDD; and I'd gotten damn good at
writing fairly bug-free code in C/C++.  However, I did used
to fear refactoring my bug-free code, for fear of having
to thoroughly manually test it again in the debugger.
In TDD, by contrast, refactoring is an integral part of
the process - with the network of tests catching refactoring
errors the same way it catches other errors while coding.
(Such as the misspellings mentioned in this thread.)

This isn't meant to preach some sort of silver bullet.
But modern TDD is pretty neat.  And it seems like time
much better spent than the stepping-through-code in the
debugger I do on a few regrettably-non-TDD projects.


Regards,

Bill