I see the issue a bit differently. If you have many private methods or private methods that are complex enough to warrant being tested, it's a sign that a new module (or class, function, namespace, etc) is waiting to come to life.
That module would essentially be a private module, not a private method or a set of private methods. A new module is easier to test than a private method because the latter might require setting up unrelated stuff to put it under test, and also, some languages won't let you call private methods.
I usually listen to my unit tests: if the examples for a particular module are in great number, messy, or cumbersome, that's a sign a new module could be extracted. That's a useful code smell to be aware of.
All of that to say you are doing the right thing by testing complex private methods, and that's part of the mindset that makes for a good testing strategy, but I'd consider extracting the private methods into first class modules.
Yeah, I saw this argument a lot when I was researching the topic for this piece. But ultimately, I couldn’t find any battle tested rules on the subject—it’s more of a feeling. In other words, when is a good time to create that new module/class?
Regardless, I’m on board. It’s hard to test a class that has too much functionality, and overly complex methods are usually a code smell. I think these types of problems have to be tackled before worrying about private method testing.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.