Unittesting and code coverage

Recently it was decided that all newly constructed code that our company builds, has to be unittested. Although this may seem like a late call, for a lot of product companies this is quite a big step and I, in contrast with a lot of developers out there, was happy to hear this...

...Until, that is, some mentioned that we should reach 100% code coverage. Now I know some of you out there would say that this should be the case, but I think differently. Let me explain.

Let's say you have some method that has to find an object in some hierarchy. At some point you end up writing some code like this:

FindableObject FindObject(string name)
{
FinadbleObject result = null;

foreach (FinadbleObject subObject in _subObjects)
{
if (subObject.Name == name)
{
result = subObject;
break;
}
else
{
result = subObject.FindObject(name);
if (result != null)
{
break;
}
}
}

return result;
}

It would work like a charm. Let's say you now write a unittest for this method. You set up a hierarchy of three objects and try to find the deepest one by calling FindObject on the top one. The result of the unittest would be a pass if the result of the method equals the initial object you placed there. Problem is, you would not reach 100% code coverage of your method, because the last } that belongs to the foreach loop would not be reached.

The only way to do this, is to write a unittest that will not render a result as it calles FindObject. Although this may very well be a valid unittest, I'd say that writing several lines of code, simply to test a closing curly bracket is somewhat over the top.

Another reason why I think having 100% code coverage in unittesting is highly impractical, is that you would have to test stuff like getters and setters on properties, even if they don't contain any code.

Please let me know if you think otherwise and have some compelling reason to still reach 100% code coverage, by dropping me a comment. I'm still open for debate on this.