TDD'ers have run a muck...

I am re-writing my Scouting paper. The idea is that if code tests are
good for upfront, why not include other types of tests or experiments?

I want to show that Software Scouting and Reconn is a natural part of
design.

I was looking for some definitions of TDD and Test First Development
so that I could show the relationship I know exists between TDD and
Software Scouting/Reconn.

I came across this:

http://www.xprogramming.com/xpmag/testFirstGuidelines.htm


The Test-Code-Simplify cycle (Quoted verbatim from "Extreme
Programming Applied", p159)

Write a single test
Compile it. It shouldn't compile, because you haven't written the
implementation code it calls

Implement just enough code to get the test to compile
Run the test and see it fail

Implement just enough code to get the test to pass
Run the test and see it pass

Refactor for clarity and "once and only once"

Repeat


I find it completely wierd that I "have to" compile something I know
will not compile. I also find it just as troubling that I have to run
a test that I know will fail.

This is what I call a methodology gone amuck. Steps for steps sake
IMO.

What is the goal of TDD?

IMO it is to help design the code. It is a design process. My
thoughts should be about "how do I want to use this system", "what do
I expect from the call into the system", "what domain terminology is
needed/used by this call into the system", "which subdomain will
handle this behavior", "what objects exist in the caller's world
versus the callee's world", you know, those kinds of thoughts are
going through my head.

What is not going through my head is following some "hard coded"
steps!

I don't think TDD has gone amuck, but I think that the description of
what it is doing is lacking.