lasse is right. that's why i stay away from generating test-case tools, which often generate test-skeletons of public methods. as an example: think about a login() method. it does not make sense to brutely just generate one testMethod testLogin(). you should look at the behaviour and create test-cases like testLoginSuccessful(), testLoginUserNotExists(), testLoginPasswordWrong() etc.. as you can see one public method often maps to different test-cases.
apart from of that there are tools which make testing private methods possible. but i would stay away from that: see your need to test private methods as a code/design smell to refactor (extract class).
Behaviors for use are exposed through public methods only and the private methods would support the exposed behavior , then why to test private methods ?
One reason could be that the private method is very complex, and it's quite hard to test it through the public interface of the class.
The answer is, of course, that this is a code smell - such a complex method belongs on a class where it'd be naturally public.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus