This section from the book Clean Code, in Chapter 10 Classes > Class Organization > Encapsulation kinda implies that testing on private method is a pseudo-proposition.
We like to keep our variables and utility functions
private, but we're not fanatic about it. Sometimes we need to make a variable or utility functionsprotectedso that it can be accessed by a test. For us, tests rule. If a test in the same package needs to call a function or access a variable, we'll make itprotectedor package scope. However, we'll first look for a way to maintain privacy. Loosening encapsulation is always the last resort.
IMHO private method is just a wrapper of a partial responsibility implementation, which is invoked in non-private method. So if testing on a private method is very important, the access scope should be enlarged so that a unit test framework like JUnit is able to run test on it. Otherwise, the only way to "test" private method is in fact the test on a non-private method, which calls that private method
Moreover, the Deencapsultion class of JMockit was removed last year. This kinda proved that "test on private method" is a pseudo-proposition