Tuesday, November 25, 2008 3:18 PM
Answer: Test Private Methods
On my previous post I have asked a question:
"Would you test a private method?"
I got a good response from Chad Myers and would like to share it with you all:
"Microsoft's opinion is in favor of testing private methods. In fact, they seem to encourage it with Private Accessors and various How To articles on MSDN.
I wouldn't say that this is just my opinion (not to test private methods), it is generally a common-held opinion in the unit testing and, specifically, TDD circles. I won't take credit for this thought, but I will say that I do hold this opinion (e.g "Do not test private methods").
I have written several large-scale enterprise apps and have not ever needed to test a private method. I'm saying this to brag or anything, I'm saying it to prove a point that it IS possible and SHOULD be a virtue worth striving for.
Having said all this, I am not prepared to say that testing private methods is ALWAYS wrong, but it's "ALMOST ALWAYS" wrong. There may be a few circumstances where it is beneficial or worth the risk of brittle tests to do this.
This is why I called it a code "stench". It's worse than a smell, but it's not universally BAD."
Now, about internal methods he said:
"I feel mostly the same about this one, but it's not quite as dangerous as private methods, so I would tone down a the warning a little. Generally, I manage to find a way to not have any internal methods also.
Internal methods usually denote direct coupling between concrete classes versus coupling through abstractions (public interfaces). This creates a more brittle framework and prevents client code from overriding functionality if it needs to.
By using the Dependency Inversion Principle and Interface Segregation Principle, along with an IoC container, I seem to never need the 'internal' keyword and very rarely need the 'private' keyword, let alone tests for the same."
Thanks you Chad Myers.
You can read his post the responses here.
I tend to accept Chad Myers opinion, however I do not agree with the statement:
"Do not test private methods".
I think you should try to avoid testing them, but there are cases that you just have no choice (I have proven it to myself... :)).
As a practice, try when you design your code, to set the all methods as public. If you feel you need a private method, try and redesign your code to use another class that exposes that method as public.
You should see that most of the time it is possible however there are cases where you will use private methods.