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

Subscribe recorders to proxies #654

Merged
merged 7 commits into from
May 1, 2014
Merged

Conversation

fables-tales
Copy link
Member

A sketch of a fix for #652

I'm not sure using playback and then sending the message is even sensible, what do people think?

Also: there was a failing spec for me locally, but it was present before this commit. It's rspec ./spec/rspec/mocks/partial_double_spec.rb:140 # Using a partial mock on a proxy object works properly

This is based on top of Myron's branch in: #651

@myronmarston
Copy link
Member

I merged my PR but the diff here is still showing that code. Can you rebase this, @samphippen?

@fables-tales
Copy link
Member Author

Done!

# TODO: this shouldn't be necessary to satisfy the expectation, but is.
klass.new.foo(2)
# # TODO: this shouldn't be necessary to satisfy the expectation, but is.
# klass.new.foo(2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just remove this like below ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imagine a universe where I am good at writing ruby. In that universe these
lines don't exist.

I'll fix it when I get back to london.

Sent from my phone please excuse my brevity.

On 7 Apr 2014, at 13:37, Jon Rowe notifications@github.com wrote:

In spec/rspec/mocks/any_instance_spec.rb:

@@ -426,8 +426,8 @@ def inspect
expect_any_instance_of(klass).to receive(:foo).with(2).and_return(2)
expect(instance.foo(2)).to eq(2)

  •      # TODO: this shouldn't be necessary to satisfy the expectation, but is.
    
  •      klass.new.foo(2)
    
  •      #  # TODO: this shouldn't be necessary to satisfy the expectation, but is.
    
  •      #  klass.new.foo(2)
    

Why not just remove this like below ;)

Reply to this email directly or view it on
GitHubhttps://github.com//pull/654/files#r11339854
.

@JonRowe
Copy link
Member

JonRowe commented Apr 7, 2014

This looks good to me but is currently failing due to some undocumented code:

RSpec::Mocks::AnyInstance::Recorder#notify

@fables-tales
Copy link
Member Author

Gonna mark it Api private

Sent from my phone please excuse my brevity.

On 7 Apr 2014, at 13:46, Jon Rowe notifications@github.com wrote:

This looks good to me but is currently failing due to some undocumented
code:

RSpec::Mocks::AnyInstance::Recorder#notify

Reply to this email directly or view it on
GitHubhttps://github.com//pull/654#issuecomment-39720623
.

@fables-tales
Copy link
Member Author

@JonRowe so you don't think the approach of doing a playback, followed by a call is quite odd here? I'm slightly worried this could have undesired side effects. Maybe @myronmarston can comment, as I said, I'm really not sure about this approach.

@myronmarston
Copy link
Member

I think the playback is problematic, too. Will respond with more thoughts later.

Sent from my iPhone

On Apr 7, 2014, at 7:42 AM, Sam Phippen notifications@github.com wrote:

@JonRowe so you don't think the approach of doing a playback, followed by a call is quite odd here? I'm slightly worried this could have undesired side effects. Maybe @myronmarston can comment, as I said, I'm really not sure about this approach.


Reply to this email directly or view it on GitHub.

@@ -22,6 +22,16 @@ def initialize(klass)
@expectation_set = false
end

# @private
def notify(object, message, args, blk)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be good to call this notify_received_message (or something similar) rather than just notify. notify, on its own, is too generic, IMO -- notify of what?

@myronmarston
Copy link
Member

So here's the part I'm struggling with: playback! creates an expectation on the object which can be fulfilled, which we can then simply call to satisfy. In the case where we're expecting with some args, we need to fulfil that expectation somehow. I don't think any of the notify message received messages accept arguments. Correct me if I'm wrong.

Do you have a spec that demonstrates this case? That would be helpful to use as we figure out a solution. Anyhow, I definitely thinking of expectation args and all that. It sounds like none of the existing methods available off of the any instance recorder will work properly to notify of the exact message expectation (with args) w/o affecting how the object responds to the message (which playback does). So I think you need to refactor the internals of the any instance recorder to expose a method like you need.

@myronmarston
Copy link
Member

I'm going to take a look at this locally, and maybe push some commits to wrap this up.

@fables-tales
Copy link
Member Author

Please do! Sorry I haven't had time to close this out. Let me know if you
need any help/explanations of anything :)

@myronmarston
Copy link
Member

OK, I made some progress and force pushed. More to come. I'm going to bed for now.

@myronmarston
Copy link
Member

OK, @samphippen, I think this is ready for review and merge.

/cc @JonRowe @xaviershay

@@ -121,6 +121,21 @@ def already_observing?(method_name)
@observed_methods.include?(method_name) || super_class_observing?(method_name)
end

# @private
def notify_received_message(object, message, args, blk)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blk is unused here. Should it be routed somewhere else?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's nothing to do with blk here (nor with object). They are passed to this method just to provide the full details about the notified message because from the point of view of the proxy calling this, it doesn't know or care which aspects of the received message the subscriber uses.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK cool.

@fables-tales
Copy link
Member Author

I left a few comments. Mostly LGTM. Also travis failed, which I'm not sure about. I'd like to give this another pass once the comments are worked through, but this is great!

@myronmarston
Copy link
Member

Do you still want to move name into the options hash? I think that'd be good.

Longer term, maybe but in the short term now. My immediate concern driving that suggestion was the explicit passing of an unnamed nil arg, but that's no longer necessary and I've removed it, so that immediate concern no longer is a concern.

@fables-tales
Copy link
Member Author

OK. This LGTM. I think merge when green.

@myronmarston
Copy link
Member

So there're two issues with the build:

  • Travis is having problems with 2.1.0: Ruby 2.1.0 problems travis-ci/travis-ci#2220
  • 1.8.7 is failing when requiring diff/lcs. I think it's a problem with bundler 1.6. This didn't happen on recent builds where bundler 1.5.3 was installed.

@@ -1,7 +1,13 @@
# This file was generated on 2014-03-30T13:16:22-07:00 from the rspec-dev repo.
# DO NOT modify it by hand as your changes will get lost the next time it is generated.

before_install: "script/clone_all_rspec_repos"
before_install:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment above says not to change this file and I don't see an obvious commit bumping it. Is cool?

@myronmarston
Copy link
Member

@xaviershay -- the build is failing on 1.8.7 when rspec-expectations tries to require diff/lcs (it gets a aLoadError`). I think it's a regression in bundler 1.6. These code you commented on is troubleshooting code because at the time I couldn't repro the failure locally, so I was pushing troubleshooting code to travis to see the output. I plan to undo all of it before merging this.

@xaviershay
Copy link
Member

seems legit

@JonRowe
Copy link
Member

JonRowe commented May 1, 2014

Apart from the travis build issues, this LGTM.

myronmarston added a commit that referenced this pull request May 1, 2014
@myronmarston myronmarston merged commit 6d5b911 into master May 1, 2014
@myronmarston myronmarston deleted the subscribe-recorders-to-proxies branch May 1, 2014 04:41
@myronmarston
Copy link
Member

Merged, since I got the build to pass finally. I've also got PRs out to rspec-dev, core, expectations, mocks and support to update the .travis.yml accordingly.

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

Successfully merging this pull request may close these issues.

4 participants