I often get the question when teaching developers test driven development (TDD), “How do you test private method?” The short answer is you don’t, but there’s also a longer answer that Michael Features gave in his book, *Working Effectively with Legacy Code.*
Certainly, you *could* test private methods, and I’ve seen developers do all sorts of tricks to make that happen—wrapping the private method in a public delegate or proxy or even accessing the private method through reflection—but perhaps having to resort to these tricks is a code smell that’s telling us something’s wrong.
Feathers points out that if you can test the private method through its public interface (the public method that calls the private method) then you can consider the private method tested and code coverage will show the private method was covered. This is why myself and others say that you don’t need to write tests for private methods when doing TDD.
But if you still feel uneasy about whether you have the behavior in the private method covered by tests then maybe something else is going on. Perhaps your private method has too much responsibility and should be broken out into its own testable class. Then the method can be declared public so it can be tested directly and the caller can hold a private reference to its class so the public method doesn’t bloat the caller’s interface.
Private methods are for hiding implementation and we don’t want to test implementation details when we do TDD, that’s better achieved as part of a QA effort, if needed.