Real world use-case of “use protected, not private”

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

evil-privateRecently I wrote an article that challenged the software accepted practice of hiding methods away using the private keyword. Instead I suggested that using protected is actually better practice. In this article, I present a real-world example of this philosophy whereby switching from private to protected makes it far easier to unit test one’s code

Consider the following code fragment:

From the perspective of writing unit tests, we are scuppered. The only publicly exposed method is the constructor, which takes a URL and performs an HTTP GET on it in order to fetch the page’s content. The method onPageComplete is completely inaccessible as far as unit testing goes. Our only option is to perform lots of system tests in the hope we fully exercise onPageComplete. In frustration, many developers would then start adding various public methods and read-only properties (getters in Java parlance) to try and get around the problem. In the process, they ride roughshod all over the class’ encapsulation.

Yet this problem arises simply because “private” was used. Change private to protected and a whole new world of unit testing possibilities are opened up. Suddenly we can create a test class that extends Process. This allows us to mock its methods and access all of its innards during the tests. This in turns lets us write unit tests – not integration or system tests, but real unit tests – that test every last little detail of the class. For example:

provides us with an override of loadPage, which prevents Process‘ constructor from attempting to load a page. This then lets up call testParsingHTML directly, ie we can run unit tests against that previously inaccessible method.

Such a technique is immensely useful for unit testing all event based code. It isn’t just limited to event handlers though, by using protected rather than private, you can simplify the unit testing of all your code.

4 thoughts on “Real world use-case of “use protected, not private”

  1. Hey thats clever. Such a neat way of mocking a class for testing might actually let me sell the switch to protected to my colleagues. Thanks.

  2. I see your pain, but my diagnosis would be that the class is doing too many things: it’s getting some HTML and then processing it. Note the conjunction in its description!

    Given that you can change this class, why not extract the ‘interesting’ behaviour inside onPageComplete into a separate unit which you can then test cleanly without worrying about HTTP?

  3. @Dave,

    The idea of describing a class and then, if it contains “and” breaking it in two is a good one. However your description is flawed. The class actually grabs images from a web page. No conjunction required unless you start describing how it does it.

    The class, whilst somewhat contrived as I wrote it for a Test Orientated Development (TOD) talk, it is fairly simple. Breaking it’s functionality up into extra classes would therefore necessitate a fair degree of coupling between those classes and would likely make the code more, not less, complicated.

    That aside, the technique is more about testing event-based functionality, rather than HTTP calls. Breaking the code up into smaller classes wouldn’t make testing private event handlers any easier.

  4. Visibility modifiers are not for the programmers sake, they are for the compilers static analysis. That is the real world use case. Use the most restrictive visibility you can get away with.

Comments are closed.