What's the best way to unit test protected & private methods in Ruby?

Question

What's the best way to unit test protected and private methods in Ruby, using the standard Ruby Test::Unit framework?

I'm sure somebody will pipe up and dogmatically assert that "you should only unit test public methods; if it needs unit testing, it shouldn't be a protected or private method", but I'm not really interested in debating that. I've got several methods that are protected or private for good and valid reasons, these private/protected methods are moderately complex, and the public methods in the class depend upon these protected/private methods functioning correctly, therefore I need a way to test the protected/private methods.

One more thing... I generally put all the methods for a given class in one file, and the unit tests for that class in another file. Ideally, I'd like all the magic to implement this "unit test of protected and private methods" functionality into the unit test file, not the main source file, in order to keep the main source file as simple and straightforward as possible.

Thanks!

-Brent

Answer 1

You can bypass encapsulation with the send method:

myobject.send(:method_name, args)

This is a 'feature' of Ruby. :)

There was internal debate during Ruby 1.9 development which considered having send respect privacy and send! ignore it, but in the end nothing changed in Ruby 1.9. Ignore the comments below discussing send! and breaking things.

Answer 2

instance_eval() might help:

--------------------------------------------------- Object#instance_eval
     obj.instance_eval(string [, filename [, lineno]] )   => obj
     obj.instance_eval {| | block }                       => obj
------------------------------------------------------------------------
     Evaluates a string containing Ruby source code, or the given 
     block, within the context of the receiver (obj). In order to set 
     the context, the variable self is set to obj while the code is 
     executing, giving the code access to obj's instance variables. In 
     the version of instance_eval that takes a String, the optional 
     second and third parameters supply a filename and starting line 
     number that are used when reporting compilation errors.

        class Klass
          def initialize
            @secret = 99
          end
        end
        k = Klass.new
        k.instance_eval { @secret }   #=> 99

You can use it to access private methods and instance variables directly.

You could also consider using send(), which will also give you access to private and protected methods (like James Baker suggested)

Alternatively, you could modify the metaclass of your test object to make the private/protected methods public just for that object.

 test_obj.a_private_method(...) #=> raises NoMethodError
 test_obj.a_protected_method(...) #=> raises NoMethodError
 class << test_obj
  public :a_private_method, :a_protected_method
 end
 test_obj.a_private_method(...) # executes
 test_obj.a_protected_method(...) # executes

 other_test_obj = test.obj.class.new
 other_test_obj.a_private_method(...) #=> raises NoMethodError
 other_test_obj.a_protected_method(...) #=> raises NoMethodError

This will let you call these methods without affecting other objects of that class. You could reopen the class within your test directory and make them public for all the instances within your test code, but that might affect your test of the public interface.

Answer 3

One way I've done it in the past is:

class foo
  def public_method
    private_method
  end

private unless 'test' == Rails.env

  def private_method
    'private'
  end
end

Answer 4

I would probably lean toward using instance_eval(). Before I knew about instance_eval(), however, I would create a derived class in my unit test file. I would then set the private method(s) to be public.

In the example below, the build_year_range method is private in the PublicationSearch::ISIQuery class. Deriving a new class just for testing purposes allows me to set a method(s) to be public and, therefore, directly testable. Likewise, the derived class exposes an instance variable called 'result' that was previously not exposed.

# A derived class useful for testing.
class MockISIQuery < PublicationSearch::ISIQuery
    attr_accessor :result
    public :build_year_range
end

In my unit test I have a test case which instantiates the MockISIQuery class and directly tests the build_year_range() method.

Answer 5

You can "reopen" the class and provide a new method that delegates to the private one:

class Foo
  private
  def bar; puts "Oi! how did you reach me??"; end
end
# and then
class Foo
  def ah_hah; bar; end
end
# then
Foo.new.ah_hah

Answer 6

Here's one easy way if you use rSpec :

 before(:each) do
    MyClass.send(:public, *MyClass.protected_instance_methods)  
  end

Answer 7

Just reopen the class in your test file, and redefine the method or methods as public. You don't have to redefine the guts of the method itself, just pass the symbol into the public call.

If you original class is defined like this:

class MyClass

  private

  def foo
    true
  end
end

In you test file, just do something like this:

class MyClass
  public :foo

end

You can pass multiple symbols to public if you want to expose more private methods.

public :foo, :bar

Answer 8

Here is a general addition to Class which I use. It's a bit more shotgun than only making public the method you are testing, but in most cases it doesn't matter, and it's much more readable.

class Class
  def publicize_methods
    saved_private_instance_methods = self.private_instance_methods
    self.class_eval { public *saved_private_instance_methods }
    begin
      yield
    ensure
      self.class_eval { private *saved_private_instance_methods }
    end
  end
end

MyClass.publicize_methods do
  assert_equal 10, MyClass.new.secret_private_method
end

Using send to access protected/private methods is broken in 1.9, so is not a recommended solution.

Answer 9

I'm sure somebody will pipe up and dogmatically assert that "you should only unit test public methods; if it needs unit testing, it shouldn't be a protected or private method", but I'm not really interested in debating that.

You could also refactor those into a new object in which those methods are public, and delegate to them privately in the original class. This will allow you to test the methods without magic metaruby in your specs while yet keeping them private.

I've got several methods that are protected or private for good and valid reasons

What are those valid reasons? Other OOP languages can get away without private methods at all (smalltalk comes to mind - where private methods only exist as a convention).

Answer 10

Instead of obj.send you can use a singleton method. It’s 3 more lines of code in your test class and requires no changes in the actual code to be tested.

def obj.my_private_method_publicly (*args) my_private_method(*args) end

In the test cases you then use my_private_method_publicly whenever you want to test my_private_method.

http://mathandprogramming.blogspot.com/2010/01/ruby-testing-private-methods.html

obj.send for private methods was replaced by send! in 1.9, but later send! was removed again. So obj.send works perfectly well.

Answer 11

To correct the top answer above: in Ruby 1.9.1, it's Object#send that sends all the messages, and Object#public_send that respects privacy.