On Wed, Aug 20, 2008 at 1:08 PM, d c <lister / pikkle.com> wrote:

> if you are looking for a proof of concept - if something works or not
> (today, and you don't care about tomorrow) then writing iron-clad
> tests for everything seems redundant. if you have a level of
> confidence, you can fly blind, and i feel get into a much better state
> of flow without tests. a week later things may not work as planned
> tho.

I understand the sentiment, but if you feel the need to write
iron-clad tests up front, you're probably not going to see most of the
benefits of TDD.
For me, the flow isn't broken if I limit each test to a single, basic
change that I'm about to make.  I don't even begin to think about edge
cases until I write tests that fail for the bare minimum basics (a
single use of a single function).   Then I write that code.  Then I
move on to the next thing.

Often times, figuring out what tests I need to write next involves
toying around with a prototype, or writing parts of my function in
IRB.  This helps me figure out how my code should work without having
to think it through mentally.  Once a get a sense of how that stuff
should work, I might refactor a bit under the green light to make room
for the new behaviour.   Then I write the new failing test, then I
write the code.

Most of the time, this doesn't cause any noticeable decrease in my
velocity, it even increases it sometimes.  Purists might say you
shouldn't write any code at all before your tests, but I think what's
important is that you shouldn't *integrate* any code before you write
the tests.  Hacking around with an experiment, so long as it's tiny
and can easily be followed by a formal test case, is always helpful.

-greg


-- 
Technical Blaag at: http://blog.majesticseacreature.com | Non-tech
stuff at: http://metametta.blogspot.com