Unit tests: the fallacy of 100% coverage

"The Hounds of Tindalos!" he muttered. "The can only reach us through angles. We must eliminate all angles from this room. I shall plaster up all of the corners, all of the crevices. We must make this room resemble the interior of a sphere."

- "The Hounds of Tindalos", Frank Belknap Long

I'm an ardent supporter of having unit tests for one's codes, having first hand experienced the benefit they give when you need to refactor code. As a result, one thing that really irks me are programmers who view unit tests as, at best, a necessary evil and therefore try to write as few tests as possible. To them, a suite of tests is good if the tests execute a lot of the code. If these programmers could achieve 100% code coverage, then they would feel their work is done: no more tests need to be written! While this belief might be true for some code, in general it does not hold true: for most classes, simply having 100% code coverage says nothing about whether the code is truly doing what it should do.