It's fascinating that the last time I saw someone cite
the first paragraph you quote there, they were using it
to argue about the *deficiencies* of unit testing!
I'm a huge fan of test-driven development - I long since
got to the point where I feel wrong if I try to write
code before I write a test.
However, I don't believe that this approach addresses
the fundamental problem that Dijkstra refers to. Whether
you write your tests first or last, if tests are all you
have, you have no way of knowing whether your program
has problems you simply haven't written tests for.
Dijkstra seems to be talking about constructing proofs
of correctness, which is a very different way of
building code from test-first development.
As Ian says, you're totally distorting Dijkstra's words.
He says "it [testing] is hopelessly inadequate
for showing their [bugs] absence". How you can
then go on to conclude that Dijkstra is in support of
test driven development is beyond me. You're just
hearing what you want to hear if you draw that
conclusion.
If anything, Dijkstra seems to be advocating formal
methods, which is something that is a 180 degree
turn-around from the agile methods most advocates of
test driven development believe in.
I've just started the move to test driven, but I notice
that I have always done some things in a test-oriented
way.
I talk about it at work and I get stranger looks than I
did when I started talking about .Net ;)
Build when you expect an error to be sure the error is
where you expect it to be.
Call code you expect to fail for the same reason.
Use functions that don't exist yet so I can see what to
call them...
I think Dijkstra is just using different terms, he is
talking about an itimate realationship between
proof(test) and functionality.
There are almost always more tests that will make the
functionality fail, but without any tests, you can't be
sure it does what you think.
I find it quite interesting how well Dijkstra's ideas
resonate with XP aproaches.
Shane: Distorting? hardly. Dijkstra's message was that
tests *before* or *during* the program are *part* of how
we should program. The fact that Dijkstra realized that
testing will never be enough to help us conclude that
there are no bugs does not subtract from the realization
that testing *after* the programming is much less useful
that before the actual work. Yes, this realization is
part of 6 simple rules that Dijkstra portrays in his
lecture. The basic theme there is that programs should
be limited to intellectually manageable programs. The
realizations that testing before coding helps you
mentally with creating the program is one of these
corner stones.
classic document. thanks for pointing it out.
To interpet argument three as promoting, rather than
arguing against, TDD is a completely backwards
interpretation. Dijsktra is clearly talking about using
proofs (formal methods) instead of testing; TDD is
testing, not any sort of proof at all. That the tests
are written first or last is of no consequence; the
tests still cannot prove the absence of all bugs in a
particular piece of code.
(Well, they could in the case where they test every
possible combinations of input and ouput, constituting
some sort of a proof through exhaustive enumeration, but
that's not practical.)