Ian Bicking: the old part of his blog

Testing considered harmful

Maybe Dijkstra isn't going that far, but it's an interesting argument against testing. He would certainly have bristled at the notion that "once your tests pass your code is done," even if tests still serve a certain purpose. Sometimes I feel I should reread my software more often. If it's not worth rereading, then it's too long and should be cut. If it is too good to need refinement, then reading it will simply make me feel happy even if I don't change it. But by rereading, I may feel more certain of the correctness of the program, as well as the conceptual integrity. Unit tests are good, but unit tests do not make code *beautiful*. Another interesting point he makes: programs are not correct, computations are correct. That is, it is the *running* of the program that must be correct, in the fullness of its environment within and beyond the computer it runs on. Indeed, this is why I believe the Turing Machine is not applicable to real programming, because no useful programs can be reduced to a Turing Machine. Useful programs are useful only because they produce useful computations, and without I/O a Turing Machine is fundamentally unable to be useful.
Created 11 Jul '03
Modified 14 Dec '04

Comments:

"Unit tests are good, but unit tests do not make code *beautiful*"

I completely agree, but this misses a common approach to the use of unit tests. Kent Beck advocates a cycle for any given test that positively does *not* say that you are done when your tests pass: in fact you're only past the second phase. He recommends that (1) you write a failing test, (2) you get the test to pass and then, crucially, (3) you refactor. (I think Kent Beck characterises it as 'remove duplication'.)

(3) can take much longer than (1) and (2) put together, not least because this stage can end up with rewriting quite a lot of code not related to the test if opportunities for improved structure emerge. This is the opportunity to make the code beautiful. The unit test gives you a better chance of not breaking the code during this process.
# Ian Griffiths