Stubs on instances of DelegateClass do not behave as expected

[philipchan-shopify]

If stubbing a method on a class whose parent class is a DelegateClass, the stub doesn't seem to be called:

class A 
  def message
    "hi from A"
  end
end

class B < DelegateClass(A)
  def length
    message.length
  end
end

b = B.new(A.new)
b.length # 9
b.stubs(:length).returns(0) # <Expectation:0x32b40 allowed any number of times, invoked never: #<A:0x32b68>.length(any_parameters) >
b.length # 9 - stub was not called

Am I setting up the stub on the instance of B incorrectly?

[James Mead]

@philipchan-shopify Hi. Sorry - I don't have a lot of time to look at this right now, but I suspect it's somewhat related to #30 and/or #589. I don't know if any of the comments on those issues give you any ideas how to work around the problem...?

[James Mead]

I'm adding this because it took me a while to find it!

DelegateClass documentation.

[philipchan-shopify]

I read through the linked issues, and I'm not sure the workaround will work in my situation - I'm trying to mock an object from a 3rd party gem and am unable to change their implementation to a different delegation strategy

[James Mead]

So just to double-check, it's the 3rd party gem that's using DelegateClass...?

[James Mead]

I had a few minutes to look at this and I've got a bit further.

I think that at least part of the problem is that the anonymous class constructed by calling DelegateClass(A) inherits from BasicObject and not Object which means it's missing Mocha::ObjectMethods in its ancestor chain which is what defines #stubs.

However, things are further complicated because it looks like calling DelegateClass(A) re-defines #stubs on the anonymous class that it returns (because A#stubs does exist). See the following code:

https://github.com/ruby/ruby/blob/909afcb4fca393ce75cc63edc7656fd95a64f0f9/lib/delegate.rb#L417-L419

I think the latter explains why calling b.stubs(...) doesn't raise a NoMethodError. However, even though it exists presumably something about the way the method is "copied" means it doesn't work correctly!

Some illustrative output:

class A; end
AA = DelegateClass(A)
class B < AA; end

p Object.ancestors # => [Object, Mocha::ObjectMethods, Mocha::Inspect::ObjectMethods, Mocha::ParameterMatchers::InstanceMethods, Minitest::Expectations, Kernel, BasicObject]
p A.ancestors # => [A, Object, Mocha::ObjectMethods, Mocha::Inspect::ObjectMethods, Mocha::ParameterMatchers::InstanceMethods, Minitest::Expectations, Kernel, BasicObject]

p AA.ancestors # => [AA, Delegator, #<Module:0x00000001041df1f0>, BasicObject]
p B.ancestors # => [B, AA, Delegator, #<Module:0x00000001041df1f0>, BasicObject]

b = B.new(A.new)
p b.method(:stubs).owner # => AA

[James Mead]

@philipchan-shopify:

I have a possible solution, although it reaches into the innards of Delegate and I've only tested it on Ruby v3.2.0. Add the following before the call to DelegateClass:

require "mocha/object_methods"
Delegator.instance_variable_set(:@delegator_api, Delegator.public_api + Mocha::ObjectMethods.instance_methods)
BasicObject.send(:include, Mocha::ObjectMethods)

This does two things:

1. Adds critical methods of Mocha's API to Delegate's list of API methods. This means these methods won't be copied onto the class returned from calling DelegateClass.
2. Adds the critical methods of Mocha's API to BasicObject. The class returned from DelegateClass inherits from Delegate which in turn inherits from BasicObect. So similarly to the example in #589, we have to include the Mocha::ObjectMethods module into BasicObject.

It's worth noting that this permanently includes Mocha::ObjectMethods into BasicObject which might give you unexpected behaviour elsewhere in your test suite. Also relying on the existence of the undocumented @delegator_api instance variable and its associated Delegator.public_api method is potentially brittle and may not work on other Ruby versions.

Can you give that a try and see whether it works in your use case?

[James Mead]

@philipchan-shopify Having spent a bunch of time investigating this, I'd really appreciate some feedback on my suggested solution - thanks in anticipation!

[James Mead]

Since I've heard nothing to the contrary, I'm going to close this.

[James Mead]

See also #622.