Gluttonous: Injecting Mocks (one way or another)

Injecting Mocks (one way or another)

kev — Wed, 30 Aug 2006 17:15:00 -0400

I’ve been playing a lot with mocks lately (and I’m a bit post happy today) so I thought I’d show off a bit of code that was useful in a patch in RailTies.

Sometimes methods are hard to mock. They aren’t calling actions on some object you can replace with a mock or the API was designed so it’s hard to inject the mock in the first place.

This bit of code lets you intercept a method call and redirect it to a mock object of your choosing:

  
  # The multiple method form
  def delegate_methods_to_mock!(klass, *methods)
    methods.each {|m| redefine_method_using_mock! klass, m }
    yield
    methods.each {|m| reset_method_using_mock! klass, m }
  end

  def delegate_method_to_mock!(klass, method)
    redefine_method_using_mock! klass, method
    yield
    reset_method_using_mock! klass, method
  end

  def redefine_method_using_mock!(klass, method)
    klass.send(:attr_writer, :mock) unless klass.respond_to? :mock=

    klass.send(:alias_method, "nonmocked_#{method.to_s}", method.to_s) unless klass.respond_to? "nonmocked_#{method.to_s}"

    klass.send(:define_method, method, 
      Proc.new {|*args|
        @mock.send(method, *args)
      }
    )
  end

  def reset_method_using_mock!(klass, method)
    klass.send(:remove_method, method)
    klass.send(:alias_method, method, "nonmocked_#{method.to_s}")
  end

So then we use it like:

  def test_process_exit
    delegate_methods_to_mock!(RailsFCGIHandler, :close_connection) do
      fcgi = flexmock()
      fcgi.should_receive(:close_connection)
      @handler.mock = fcgi
      @handler.stubs(:when_ready).returns(:exit)
      @handler.process!
    end
  end

What happens is that an accessor is placed on the object in question and the method you want the mock to intercept is redirected to call on the mock instead… so it goes like this:

I call someobject.blah(1,2,3) which would normally call someobject.a(1,2,3) (may be a protected method) but instead we redefine a to call @mock.a(1,2,3) so we can register the call.

I’m not entirely sure if this is the best way to handle it but it seems to be working for my needs at the moment.

"Injecting Mocks (one way or another)" by Kevin Clark

Thu, 31 Aug 2006 12:42:59 -0400

James, It does indeed. That’s why I contacted you about the licensing.

"Injecting Mocks (one way or another)" by James Mead

Thu, 31 Aug 2006 06:23:10 -0400

This looks very similar to early versions of the Stubba component of Mocha. We also started off using blocks, but found the syntax quickly becomes less readable when you want to mock multiple methods, or even multiple methods on multiple classes – this is why I moved to using the TestCase teardown to revert classes back to their original definition. Another evolution of Mocha was to add the “expects” and “stubs” methods to the Object class to make the tests even more readable.

If I’m not mistaken, your example above includes use of Mocha does it not?

  @handler.stubs(:when_ready).returns(:exit)

"Injecting Mocks (one way or another)" by Rails

Wed, 30 Aug 2006 19:58:38 -0400

Excellent explanation here for the Mock injection. I’m also pretty sure there’s other ways of handling that but nothing springs to mind off the top…