Garry Pilkington


Application Developer
Liverpool, UK

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"

Comments

No Comments