Stubs on instances of DelegateClass do not behave as expected about mocha HOT 9 CLOSED

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

from mocha.

@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...?

from mocha.

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

DelegateClass documentation.

from mocha.

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

from mocha.

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

from mocha.

@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?

from mocha.

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

from mocha.

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

from mocha.

See also #622.

from mocha.