[ruby-talk:26598] Re: Ruby vs. Python: Decisions, Decisions

>>         http://www.c2.com/cgi/wiki?TestDrivenDesign
> 
> Am I the only one who things this is an overly hyped approach?

Are you the only one who has not tried it?

Not using Goto was hyped, and folks found other ways to tangle their code. 
Using OO was hyped, and managers dreamed of reusing every single object 
until reality woke them up. UML was hyped, and many folks called themselves 
"architects" and made a lot of money without ever writing a line of code. 
Question hype, but sometimes a good idea gets stuck inside it along the way.

> There were an example of a scorecard design developed using test first and
> pair programming.
> Several groups added their solution to the same concept until someone
> eventually showed that the testcase would have cleared a program the was
> extremely small and didn't do what you would have expected.

When you show that, you fix the test case so it exposes the bug.

/Refactoring/, by Martin Fowler: "Don't let the fear that testing can't 
catch all bugs stop you from writing the tests that will catch most bugs."

Another issue to ask of the above anecdote is (regardless of whether they 
were pairing or waving dead chickens or drawing UML) is what level of 
granularity they tested at. The level should be very small.

You are not being very Pragmatic. ;-)

> 
> I'd rather spend the time designing the code properly rather than
> designing the testcases properly.

That's why I design before during and after coding. I am fearless to change 
existing (test-infected) code in any way necessary to improve its design. 
And because test-first keeps my bug hunts down to a minimum (a fact, not a 
guess), I have more time to design.

> I do test my code, but that is not how I develop. I develop my thinking
> hard about what the application should do.
> Then I come up with a solution. Then I think about how I could break that
> solution be searching for counterexamples.
> When I'm, fairly confident that the design is sound, I implement the
> solution. Then I test that it works as expected by generating test cases
> to catch stupid errors. I do not let the trivial testcases drive my
> design. They will not find the major logical flaws anyway.

For many, these big chunks add risk. A lifecycle that's more idiot-proof 
would alternate tiny sessions of design with tiny sessions of coding and 
tiny ones of testing, repeating over and over again. Test code is easy to 
write, so write it first; and use it to help you write the production code. 
Design is hard, so do it last. Engineers always try to defer the hard 
decisions as long as possible, until they become easy.

-- 
Phlip

http://www.greencheese.org/HatTrick