Private Methods: To Test or Not To Test?

{{{
Recently I sat in a job interview, we were TDDing a data structure. That was fun, but it turned out that one big minus for me was that *I insisted on testing a private method*.

I still believe that when writing a class that’s reused in multiple places (maybe as a gem) you have to *test both the public and the internal API*.

Here’s a very abstract example to discuss.

h3. Example: A Helper.

Let’s say we were writing a helper method to join two strings and format them appropriately. I know, the example is more than stupid.

class Hello
  def welcome(name)
    name = sanitize(name)

    "Hey, #{name}!"
  end

private
  def sanitize(string)
    # do whatever you want
  end

The welcomeing process involves tWO steps. First, it removes unwanted chars from the name string *using a private method* (line 3). Then, the greeting is joined and returned (line 5).

To render the string, you’d do something like

Hello.new.welcome("Ryan")
  #=> "Hey, Ryan!"

h3. Testing the public API

Now, since we ship this really useful helper “in its own gem”:http://rubygems.org/gems/hello_helper we have to test the public API thoroughly.

it "does not sanitize good names" do
  welcome("Ryan").should == "Hey, Ryan!"
end

Naturally, we’d also test edge cases to see if the complex internal logic works. For example, what if the name contains unsolicited markup?

it "removes HTML" do
  welcome("Ryan").should == "Hey, Ryan!"
end

And so further and so on. Testing the public API with edge cases usually is a good thing. “In my gems”:https://github.com/apotonick/cells/blob/master/test/rails/render_test.rb, I have so called *”API tests” which test the public interface, only*.

h3. Testing in Public – Guilty as Charged!

Testing your public API, only, brings certain benefits

# It’s *less work* as you’re testing less methods, resulting in fewer test cases.
# You *don’t have redundancies* in your tests. All egde cases are asserted on the public API, only, and you don’t do that on your private methods, again.
# Your *test are more stable* since they don’t have to change after an internal refactoring. Given the case you’d rename @#sanitize@ you don’t have to touch your test as you did not test the @#sanitize@ method at all.

Apparently, I can see those advantages and this is where I agree with my interview mate. However, what if a private method yields a certain level of complexity? What if my @#sanitize@ method goes crazy, removes HTML, swipes out SQL injections and donates to Greenpeace at once, all-in-one?

*I don’t want to run all those tests through the public API* – and there is absolutely no point against testing a private method.

h3. Let’s Go Private!

Testing private methods often makes sense, and I “push those tests”:https://github.com/apotonick/cells/blob/master/test/cell_module_test.rb into so called “Unit Tests”. This might be a different context, scenario, or test file, depending on the test framework I chose.

it "removes HTML" do
  sanitize("Ryan").should == "Ryan"
end

it "removes SQL" do
  sanitize("DESTROY *Ryan").should == "Ryan"
end

*This approach creates redundancy.* Some of the cases may have also been covered in the public test, yet. There’s a thin line between redundancy and better-maintainable code.

Anyway, when testing a private method we get benefits as well.

# *Bugs can be spotted much faster* when writing a provoking test against the concerned private method. As I know the bug is somewhere in @#sanitize@, why should I run through the entire public method stack?
# *Tests are less complex* and thus easier. Testing @#welcome@, only, obfuscates my output and my test. If I want to test if the sanitizer works, I don’t want to be greeted with an annoying “Hey!” in every test case.
# *Private tests are focused* on the problem the separated methods solves and don’t involve outer methods, which might introduce bugs as well.

h3. Test Privates – Or Not?

When I started with “API” and “Unit” tests I created tons of redundancy. As I kept refactoring lots of tests would break resulting in a bit of work. So *reducing private tests seemed to make my tests more stable* towards refactoring.

However, if there is a private method that makes me feel nervous due to its complexity (I’m talking about 5 lines of code, not 45), I tend to write “Unit” tests against it.

What are your experiences? Are there any rules-of-thumbs, pros or cons I forgot? Let us know and feel free to comment!
}}}

Advertisement