> Do i skip testing these types of methods ... ?

If you can give me coverage I'm fine with that. 

Unit tests always go against an API. Not everything has to be considered part of that API. How you remove stuff from being considered part of that API is up to you. Insisting it's always every non-private method is just hiding behind a brain dead rule. One that predates code coverage tools.

There should be some deterministic lump of code we call a unit under that API that might have many methods and objects hiding inside it. You give me tests that cover it well and I'm not going to insist that every accessible method be called directly. Just show me a convincing coverage report.

Now that said, I'm also not opposed to developing a private method with unit tests. The thing is, keep those tests to yourself. Don't commit them. Because while they may help you write this method they'll lock down an implementation choice later that we don't want to be slaves too. We want to test behavior as loosely as we can. That enables refactoring. It's not fun having to rewrite tests every time you change code.

Why do I have to be this paranoid? Because people are cowards when it comes to deleting old useless tests. They'd rather drag them around. That makes me conservative with what I allow. Document when a test should die well and maybe I'll relax a little. Maybe.