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