The consensus seems to be not to test private methods when doing TDD.
Should Private/Protected methods be under unit test?
I keep hitting this same scenario. I have a private method (as an example it switches all options to off). It changes lots of state and is called by a few public methods. The changes that the private method makes to the state will remain the same regardless of which public methods get called (all options get set to off).
What’s the best way to test the functionality of this private method without adding many tests that effectively do the same thing?
btw, I’m using QUnit to test Javascript objects.
Here is an overly simplified version of my class.
http://jsfiddle.net/twistedinferno/UMgAx/
Edit
What I’m really trying ask here is not ‘should I or shouldnt I test private methods’ as that has already been answered and the answer to that is no. I want to know how do I best test each public method bearing in mind that many of the assertions will be the same due to the use of my private method. The same private method gets called by many public methods. Is it ok to have a lot of duplicate assertions to test the change of state that occurs when each one of many public methods call my private method?
new fiddle with tests
http://jsfiddle.net/twistedinferno/JHzWh/
Test the public methods.
Or, more generally, test the outwardly-visible interface for the object.
If the private method is used by the public methods, its use will be tested as a result. But the private method itself, being private, isn’t a concern for anything outside of that object, including the tests.
These tests shouldn’t know or care that such a private method even exists, let alone whether or not they’re testing it. They should test all public functionality.
If the many tests are doing the same thing, might that be an indication that there’s unnecessary overlap in the public functionality? Maybe there’s room for re-factoring there? It’s entirely conjecture without seeing any code, of course. Can you provide an example?
Edit
The additional assertions duplicate the same keystrokes, but the tests are distinctly different because they’re testing different outward-facing functionality. You can always refactor out the duplicated assertions into a single function that each test calls. Sort of a custom aggregate assertion. As long as the public methods continue to have the same observable (and testable) behavior then that’s fine. As soon as one changes, its test will need to change as well of course.