> like the devs who insist that private/internal methods should not have unit tests Because unit tests for private/internal methods aren't required. They are t

> like the devs who insist that private/internal methods should not have unit tests Because unit tests for private/internal methods aren't required. They are tested via the testing of the public methods. If a test coverage analysis reveals that your private/internal methods weren't fully tested, then that tells you one of two things: 1. Your public methods weren't fully tested. Your test coverage analysis should reveal if that is the case. 2. Your private/internal methods were overengineered. They include functionality that isn't being used. Both of these are problems, but problems of a different kind. You shouldn't ignore (1), but (2) can be addressed in a myriad of different ways - including not addressing it. (2) is indicative of a development process issue more so than a defect in a development artifact.