clipka wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Not TDD. TDD is "the test is the specification." If it passes the test, you
>> don't change anything, and if it doesn't, it's broken by definition.
> 
> To me, that seems like a *very* stupid way to design your code.

It depends on what you mean by "design", really. I think this particular 
discussion I linked to exemplifies it well. The person running the meeting 
knew what he wanted and what tests had to pass.

Let them finish the entire game, then say "by the way, we want a GUI 
interface also", and all of a sudden the whole "don't do it as a grid" thing 
falls apart.

> I'm really a fan of PbC; 

I agree. PbC is also fairly close to "functional" (in the Haskell sense of 
the word) also.

> I have found that in complex systems, it's all about well-defined interfaces. If
> your interfaces are poor, the best unit implementations will get you nowhere.

Agreed. The contention of the TDD people is that by writing the tests first, 
you're specifying the interfaces. I just don't find that's a good idea.

For example, I have a library called "S3" where error codes come back as a 
list whose first element is "S3", whose second element says (basically) 
whose fault it is (yours, the ISP, the server's, etc), and the third thru 
Nth tell you what the error was in increasingly more detail. If I did TDD, I 
wouldn't have a flag on the front saying it was my one and only library that 
threw the error. (Alternately, one could say my exception hierarchy is 
rooted in an exception specific to my one library.) This isn't the sort of 
thing you do with TDD - you don't start creating a hierarchy of exceptions 
that make the library play well with others until you actually run into 
other libraries that don't play well. I guess maybe you could say it isn't 
needed, but what you wind up with is a fragile design that's constantly in 
need of being fixed because it wasn't thought out well.

I.e., TDD is "we're too stupid to think out a design far enough to have a 
good idea what we'll need."  You shouldn't be designing stuff, if that's the 
case.  And stay the *hell* away from my database schema.

> Yeah, module testing is a good thing, but specifying interfaces by virtue of
> test cases... yuck!

Yep.  I think a good insight was that TDD is really "separate your code into 
functional and side-effectsful pieces." Then the TDD tests the functional 
part without testing the side effects. The side-effects get tested as a 
"gee, we hope our functional emulation of the stateful server is right."

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message