It’s been bothering me more and more lately. I keep seeing methods that used to be private now having package private scope to allow them to be tested. I have to admit, it’s a very convenient way to get access to a method to allow it to be tested but I would argue that is only the case when you are retro-fitting tests to an untested code base.

Perhaps I should qualify the title of this blog with “In TDD, …”. I say this because I can’t see how you would ever get yourself into the situation when following TDD principles. The only way you would introduce a private method when TDDing is as a refactoring, and since the method calling it will have been test driven (and testing behavior, not implementation details) I wouldn’t feel the urge or see the value in testing those private methods.

Obviously if the behavior becomes more complex and the work done in the private methods expands, then not testing them makes me less and less comfortable. It’s at this point that I tend to focus on the single responsibility principle for class design and see if there is another abstraction or refactoring I can make which will remove the need for complex, private code. I don’t always spot it though and sometimes I decide it’s not worth the effort and incur the potential technical debt…or god forbid, make it package private to test 😉  It’s not a black or white issue which is why I treat it as a code smell, but I always feel I’m missing a trick when I have to resort to package private scope to test some code. I’m curious if other people feel the same way. I mentioned this to Dave, my pair yesterday, and he didn’t seem overly concerned about it.