This is one of those debates I'd have totally gotten into a few years ago and now just cannot be bothered. I have my own set of testing approaches and preferenc

This is one of those debates I'd have totally gotten into a few years ago and now just cannot be bothered. I have my own set of testing approaches and preferences that _usually_ work, but sometimes something else makes more sense and then I do that. Sometimes I find it is just more efficient to test `privateFunctionA()` and fail out early. This does not prevent me having a test for `publicFunction()` that runs through `privateFunctionA()`, `B()`, `C()`, and `D()` to test the full flow of interaction between them. I refuse to make a function public _just_ to test it and would like my public interfaces to be as small as possible. This means a lot of private behavior to test underneath, and sometimes it just makes sense for me to test those chunks individually. Many people wouldn't agree, and that's cool - it just means another approach works better for them. If I have a choice and am writing something from scratch, I'll do it my way. If I'm working in an existing codebase I'll err toward sticking to the existing standard (or suggest changing it if I don't think it's working very well).