You should be able to get the code coverage you need (even if 100%) by testing the public API of any class. If this isn't true, it means you have some private m

You should be able to get the code coverage you need (even if 100%) by testing the public API of any class. If this isn't true, it means you have some private methods you can delete. That's how the unit you're testing is used - through it's public API. The public API is the specification of how it works. By only testing the public API, you allow yourself maximum ability to refactor in the future, while still maximizing code coverage. It means that simple refactoring (inlining methods, for example) won't break tests. More importantly, a failing test means something is wrong that is potentially relied upon elsewhere. If you test private methods, you will get test failures without the public API of the unit having changed at all. Your point about "each function is a unit" is fine, you can justify testing private methods with that - but it's inefficient. If it's not necessary to be in the spec (public API), why have you made it so? You're over-complicating the design by locking yourself into implementation details in places where you don't need to. In my experience I've found that testing private methods directly is a code smell. It shouldn't be necessary.