Test Coverage

100% test coverage doesn't mean that every method has a test.

100% test coverage means that every code path has a test.

Helper methods, getters and setters, etc. will be tested by testing the business logic that uses them. The tests express the business logic, not the implementation.

For example, this does not need to be tested:

public int GetFooValue()
{
  return this.fooValue;
}

This, however, does:

public void UpdateSomethingBasedOnFooValue()
{
  if (GetFooValue() > SOME_BUSINESS_CONSTANT)
  {
    SomeExternalSystem.Update(GetFooValue());
  }
}

It's a contrived example which has no actual business meaning, of course. So I should add context...

If the business doesn't know what a FooValue is, if it's an implementation detail that means nothing to the business, then it's not part of the tests.  It's not a requirement that came from the business and isn't translated into a test.  However, the business does care about "updating something base on something else."  That was a requirement, and it means something to the business.  That has tests.

Any time I see implementation details with direct tests (such as pass-through DAL methods with no logic, getters or setters, or just about any private method), I immediately suspect that the tests weren't actually created to validate the business logic and requirements.  But that, instead, they were created after-the-fact, possibly by the same developer who wrote the code.  This dramatically increases the chances that the tests are worthless.