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.)