Well, the weakness I speak of is not so much that that it will never get
to the point of being stable, but that it introduces a temptation to
release early without taking the time to critically look at what might
go wrong, based on your knowledge of how it is implemented.
So more of a timing thing than a "it will never get there" thing.
Adam K
chromatic wrote:
On Thursday 30 March 2006 07:32, Adam Kennedy wrote:
In contrast, as I hear chromatic express it, TDD largely involves
writing tests in advance, running the tests, then writing the code.
Not quite. It means writing just enough tests for the next testable piece of
the particular feature you're implementing, running them to see that they
fail, writing the code to make them pass, then refactoring both. Repeat.
The important point that people often miss at first is that it's a very, very
small cycle -- write a test, write a line of code.
(The second important point is "refactor immediately after they pass".)
In my use of Test::MockObject and UNIVERSAL::isa/can I found I was
initially able to cause them to fail quite easily with fairly (to me)
trivially evil cases that would occur in real life.
For the most part, they weren't trivially easy cases that came up in my real
life, so I didn't think of them. I don't feel particularly badly about that
either. The code met my initial goals and only when someone savvy enough to
use the code in ways I had not anticipated it found edge cases did the
problems come up. I suspect you had little problem working around them until
I fixed them, too -- at least in comparison to a lot of other programmers
without your evil southern hemisphere nature and experience.
This I think (but cannot prove) is a TDD weakness, in that it might
encourage not critically looking at the code after it's written to find
obvious places to pound on it, because you already wrote the tests and
they work, and it's very tempting to move on, release, and then wait for
reported bugs, then add a test for that case, fix it, and release again.
It seems more like a weakness of coding in general. I don't release code with
known bugs, but I expect people will report bugs. Then I'll add test cases,
refactor, and learn from the experience.
Compare the previous version of UNIVERSAL::isa to the version I released. Not
only does it have far fewer bugs, but it's at least an order of magnitude
more readable. Without knowing how people will use it, it would have been
much more difficult to write the code as it stands now.
You see it as a failure or weakness of TDD. I see it as a success -- there's
better code in the world now because of it. TDD to me is one process of
soliciting and acting on feedback. Releasing code with its tests is another.
It might be worth discussing the tradeoff between releasing early (with tests
and the expectation that bug reports will become tests) and releasing after
exhaustive "What could possibly ever go wrong here?" tests, but that's a
different discussion.
-- c
