Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stubs on instances of DelegateClass do not behave as expected #621

Closed
philipchan-shopify opened this issue Oct 31, 2023 · 9 comments
Closed

Comments

@philipchan-shopify
Copy link

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?

@floehopper
Copy link
Member

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

@floehopper
Copy link
Member

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

DelegateClass documentation.

@philipchan-shopify
Copy link
Author

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

@floehopper
Copy link
Member

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

@floehopper
Copy link
Member

floehopper commented Nov 1, 2023

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

@floehopper
Copy link
Member

@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 BasicObjects do not have mocha ObjectMethods #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?

@floehopper
Copy link
Member

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

@floehopper
Copy link
Member

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

@floehopper
Copy link
Member

See also #622.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants