Do you test your private methods?

There is ample discussion on the blogosphere as to why you should or shouldn't test your private methods. 

In the 'NO camp'

http://www.redhillconsulting.com.au/blogs/simon/archives/000119.html, http://www.lostechies.com/blogs/chad_myers/archive/2008/11/21/do-not-test-private-methods.aspx

In the 'YES camp'

http://beust.com/weblog/archives/000303.html

I think there is some confusion as to why you should or shouldn’t.

Test-Driven Development

If you personally are practicing TDD then you are testing a whole chunk of code before and after refactoring. If your code passes the tests before refactoring, then you can be sure that any extracted methods are covered. That is to say you don’t need to test these methods (private or public) as their containing code have tests already.

Ok so you write your test, it fails. You then write your code to make the test pass. You are green. Then you refractor. After you refractor, you realize the method can be made private as nothing outside the class needs to know it is there. So now you have a private without any immediately related test (even though it is actually covered with the pre-refractored test).

Now if at some point in the future another developer comes along and adds a private method without any associated test; you now have two private methods, one with a test, one without. A quick glance at the source code of the test suite may not show that the first private method is covered. Perhaps forcing a rule that all methods should be tested should eliminate those non tested methods from creeping in. It may be a case of refactoring your tests to make sure each method has at least one associated test.

Regression testing

If you are working with legacy code and you are required to make changes to some public or even private methods, it would be wise to wrap tests around these methods, that way you can be sure they are functioning the same after the changes as they were before. This would be the same case for both public and private.

Code Coverage

Code coverage is the extent to which code has been tested; that is all code. So if you have 2 public methods and 98 private methods (just for example, this would be a ridiculously large class) and you have tests only for the public methods and not the private ones; do you have 100% code coverage? I wouldn't say so. I wouldn't be confident with a situation where I don't have any coverage of private methods.

I like the quote from  Cedric Beust post.

"if it can break, test it"

6 Comments

  • I agree. Those that do not want to test private methods are either:

    1) Lazy
    2) Too wound up in internal religious methodologies to get their head around the fact that actual people use their product,not just testers.

  • @Ryan:

    Those that do not want to test private methods know how to design such that testing private methods directly is unnecessary (as they get called via the public interfaces).

    They understand that if you're trying to test private methods you're doing it wrong and don't understand some of the basics of proper design.

    Try again, and try to be less of an ass next time, ok?

  • If you feel you need to test private methods, your design needs to be changed.

    In my case, I extracted all my private methods into an external class and used dependency injection pattern to insert it into the first class.

    Even better, you can then mock that class and test the first class without depending on the second.

  • @Chad: 100% agree with you.

    @Garry: "Code coverage is the extent to which code has been tested; that is all code. So if you have 2 public methods and 98 private methods (just for example, this would be a ridiculously large class) and you have tests only for the public methods and not the private ones; do you have 100% code coverage? I wouldn't say so. I wouldn't be confident with a situation where I don't have any coverage of private methods."

    Could you please explain to me HOW your private methods will be called? Cause if they are not called through your public interface, you might wanna get rid of them as they are pretty useless...

    @Ryan: If you leave your unused private methods in... that's what I would call lazy.

  • @Ben: A previous project I have worked on needed some serious changes made to it, I used tests for my private methods just to make sure that they continued to work in the way I was expecting them to. I am afraid there was no chance I could devote the time to change the design. Dependency injection is an area I am wanting to look into in the near future, I am hoping to include it on my next project.

    @webbes: All my private methods are called from public ones. I agree they would be useless otherwise.

    @All: Thanks for your input guys. I know my design methodology is not what you would call great. I am trying to improve it on each project I work on. It is only the past year that I have started using unit testing and only this past month have been looking at mock frameworks. I will get there eventually.

  • Yes Y`re all right

Comments have been disabled for this content.