The problem with unit tests

Interesting:

Unit testing is of course not just an issue in object-oriented
programming, but the combination of object-orientation, agile
software development, and a rise in tools and computing power
has made it de rigueur. As a consultant I often get questions
about unit testing, including this real one from a recent client of
mine, Richard Jacobs at Sogeti (Sogeti Nederland B.V.):
My second question is about unit tests. If I remember correctly you
said that unit tests are waste. First, I was surprised by that. Today
however, my team told me the tests are more complex than the
actual code. (This team is not the original team that wrote the
code and unit tests. Therefore some unit tests take them by
surprise. This current team is more senior and disciplined.) In my
opinion, now that’s waste… When I was programming on a daily
basis, I did make code for testability purposes but I hardly wrote
any unit tests. However I was renowned for my code quality and
my nearly bug free software. I like to investigate WHY did this work
for me?
You’ll remember from your trade school education that you can
model any program as a Turing tape, and what the program can
do is somehow related to the number of bits on that tape at the
start of execution. If you want to thoroughly test that program,
you need a test with at least the same amount of information:
i.e., another Turing tape of at least the same number of bits.
In real practice, the vagaries of programming language make it
difficult to achieve this kind of compactness of expression in a
test so to do complete testing, the number of lines of code in
unit tests would have to be orders of magnitude larger than those
in the unit under test. Few developers admit that they do only
random or partial testing and many will tell you that they do
complete testing for some assumed vision of complete. Such
visions include notions such as: “Every line of code has been
reached,” which, from the perspective of theory of computation,
is pure nonsense in terms of knowing whether the code does
what it should. We’ll discuss that problem in more detail below.
But most programmers think of unit testing this way, which
means that it’s doomed to fail from the start.
☞ Be humble about what your unit tests can achieve,
unless you have an extrinsic requirements oracle for the
unit under test. Unit tests are unlikely to test more than one
trillionth of the functionality of any given method in a
reasonable testing cycle. Get over it.
(Trillion is not used rhetorically here, but is based on the
different possible states given that the average object size is four
words, and the conservative estimate that you are using 16-bit
words).

… You can get the application code
mass down, but that code contains loops that “cheat”
information theory by wrapping up many lines of code in a
small space. That means that tests have to be at least as
computationally complex as code. You not only have many tests
but very long-running tests. To test any reasonable combination
of loop indices in a simple function can take centuries.