> If your public method requires extensive mocking but the core logic you need to protect is isolated in a private method that requires little mocking, the most

> If your public method requires extensive mocking but the core logic you need to protect is isolated in a private method that requires little mocking, the most effective use of developer resources may be to just test your private method. When I did unit tests in C++, I found a simpler (and better) solution: Shrink the class by splitting it up into multiple classes. Often the logic in the private methods could be grouped into 1-3 concepts, and it was quite logical to create classes for each of them, give them public methods, and then have an instantiation of that class as a private member. Now all you need to do is write unit tests for those new classes. Really, it led to code that was easier to read - the benefit was not just "easier to test". Not a single colleague (most of whom did not write unit tests) complained. I've yet to run into a case where it was hard to test private behavior via only public methods that couldn't be solved this way.