My perception is that much of the problems associated with testing is that the act of testing is an explicit and deliberate (and necessary) violation of the DRY principle ("Don't Repeat Yourself"), also known as once-and-only-once.

The rational of DRY is that if you state a fact twice, then when you change it then you need to change it twice. This doubles the inertia inherent in the code, and thus slows down progress (defintion of interia from physics: resistance to change).

The majority of unit test that I've seen (obviously an infinitesimal minory of those that exist) tend to be poorly factored. It's not uncommon to see code along the lines of:

is sqrt(4), 2;
is sqrt(16), 4;
is sqrt(9), 3;
[download]

Which repeats 3 times the the facts that: a function to evaluate square roots exists, that this function is named "sqrt", that it takes a single numeric argument, and that it returns a numeric value! Change any of those facts and the whole set of tests needs to be revised! Moving to a data-driven approach can mitigate this problem somewhat, but never entirely eliminates it. It can't, because the basis of testing is to violate DRY.

In this example, the facts being repeated may seem somewhat trivial, but as a general rule, the duplication acts to magnify the impact of imperfect design decisions: the added inertia may cause people to delay a needed refactoring; and the refactoring may itself need to be staged to avoid a scenario where both the tests and the implementation change simultaneously (e.g. renaming the sqrt function, above, would cause you to change both the tests and the implementation: a purist would tell you to first add the new function to delegate to the old; then change the callers; then the tests; and finally replace the delegation with the original implementation. It's not surprising that some of us give in to the temptation to take shortcuts!

Ideally, the violation of DRY that is the purpose of testing should be realized in a form that is as different as possible from the implementation being tested. Embedding the information as static type systems to be checked by a compiler; or as DBA (design by contract) to be verified by proof tools tend to form stronger whitebox tests than the simple test-by-example that, from my limited perspective, seems all too common.