|
![](/i/fill.gif) |
clipka wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |