I am wondering if unit testing private methods is a good practice?
Normally only public interface should be tested.
However, I have found out that during com
IMHO it's a very good idea, I do it all the times. I usually create a helper class which makes the private methods accessable and test it..
Usually it's even easier to test private methods, since they do something very specific. On the other hand you might have a big public method which is a bit harder to test. So it certainly simplifies unit tests.
If your private methods are complex enough to warrant testing, you're likely missing some classes where those private methods are turned public.
You certainly can test private methods, but you should take the need to do it as a hint there's something wrong in your design.
Which part of your code base is your private methods relying on ? If somebody changes the way one of the method you are relying on works and thus breaks your method, isn't it worth knowing it ? Testing is not only for checking that your method behaves as it should, but also to check that changes in other parts of the codebase doesn't break your method.
So unless your method is only using basic constructs of your language, test it !
It's not a good practice (yet that doesn't mean you should never do that), and if possible you want to avoid it. Testing private method usually means your design could be better. Let's take a quick look at your player example:
moveToFilePos
: sounds more like a responsibility of something doing I\O operations, not a music player'sfillBuffers
: more of a memory manager's job rather than music playercheckIfValidTimeRange
: again, probably could be moved out of player's scope to some simple validation class (seems like this one might be useful in other places aswell)At the moment your music player does I/O, memory management and what not else. Is that all really in scope of its responsibilities?