Geoffrey Young wrote:
> "Only the simplest of designs benefits from pre-coded tests, unless
you have
unlimited developer time."
needless to say I just don't believe this. but as I try to broach the
test-driven development topic with folks I hear this lots - not just that
they don't have the time to use tdd, but that it doesn't work anyway for
most "real" applications (where their app is sufficiently "real" or "large"
or "complex" or whatever).
Isn't this just a specifications issue? Simple designs are easier to
specify fully. More complex designs aren't so easy to specify -- or
rather, the time to specify 100% of cases isn't always practical.
I would imagine that TDD breaks down if figuring out "correct" behavior
takes longer than whipping up something that looks right most of the
time and that the end customer will pay for.
I would imagine that it also breaks down when testing things at too high
a level with too many degrees of freedom.
Still, there's no reason that TDD can't be used for the well-defined
parts of a big project, or used at the unit level where behavior has
fewer degrees of freedom. Then the benefits in terms of positive
reinforcement of task completion and the safety net against future
breakage still apply.
David Golden
