Answer: Test Private Methods

25 בנובמבר 2008

תגיות:
3 תגובות

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.

My Opinion


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… :) ).


Try This…


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.

kick it on DotNetKicks.com

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

3 תגובות

  1. Arnon Rotem-Gal-Oz25 בנובמבר 2008 ב 23:28

    "As a practice, try when you design your code, to set the all methods as public"

    Now, why would you want to do that?!?!
    you should try the exact opposite – encapsulate the internals of your class and only expose a few selected methods (the class's interface)

    להגיב
  2. kolbis26 בנובמבר 2008 ב 2:03

    Hi Arnon,
    let me explain… try to do that…you should fail (because of X reasons), right? So, instead of using private methods, try and move the methods into a new class, make this methods public, and use them internally in the first class. As I said, you will fail some of the time, however you will get classes that has the exact responsibilities they need.

    להגיב
  3. Christina 27 במרץ 2012 ב 23:13

    So-so. Something was not impressed.

    להגיב