The Fallacy of 100% Code Coverage

Re: Testing (TDD, BDD, etc.) ... from Binstock on Software [yes, again! ;-)]:

So, let's start at the foundational level: 100% code coverage is a fallacious goal. Unit testing is designed to provide two principal benefits: 1) validate the operation of code; 2) create sensors that can detect when code operation has changed, thereby identifying unanticipated effects of code changes. There is no point in writing tests that do not fulfill one of the two goals. Consequently, a getter or setter [i.e. "properties" in the .NET world] should not be the target of a unit test:

public void setHeight( float newHeight ) 
	{ height = newHeight; }

This code cannot go wrong (unless you believe that your language's assignment operator doesn't work consistently ;-). Likewise, there is no benefit in a test as a sensor here. The operation of this code cannot change. Hence, any time spent writing a unit test for this routine is wasted.