Don't silently ignore arbitrary method expectations when combining them with 'and_call_original'

[JonRowe]

I had a discussion with @myronmarston about a problem I ran into during the conversion of our RSpec suite to the new expect/allow syntax. The gist of it can be found here.

Funnily what I thought was a bug, never quite worked the way I thought it was and I refactored the spec after reading his suggestions. Myron asked me to also add an issue for it, though. So here we go :-)

The spec we talked about had used the following expectation.

CachedUser.should_receive(:where) do |args|
    expect(args[:id]).to have(3).items
    expect(contact_ids).to include(*args[:id])
end.and_call_original

The values passed to 'where' are sort of random so you can't really setup an argument matcher with 'with'. That's why we tried to verify them in the block. The whole code under test there was also part of an AREL call comparable to this one. That's where the 'and_call_original' came into the game

CachedUser.where(id: random_related_user_ids).all

The spec passed. Though, as Myron pointed out, 'and_call_original' completely replaces the block expectation, resulting in the inner expectations never to be executed.

That was a bit surprising to find out, but to be honest also a fault on my side, since I probably never saw the expectation fail in the first place :-/

To make that behavior more obvious I think it would be good to either raise an exception or to output a warning in that case.

[coveralls]

Coverage decreased (-0%) when pulling c05a378 on warn_when_overriding_implementation into 9202615 on master.

[coveralls]

Coverage decreased (-0%) when pulling c05a378 on warn_when_overriding_implementation into 9202615 on master.

[BjRo]

Awesome, thx!

[BjRo]

Awesome, thx!

[myronmarston]

I think RSpec.warn reads better (as its a verb) than RSpec.warning (as warning is a noun). Thoughts?

[JonRowe]

This matches up with the stuff in rspec/rspec-core#1024, happy to have that discussion there :)

[myronmarston]

In @BjRo's gist, it also came up that an expression like this:

      expect(CachedUser).to receive(:where) do |args|
        expect(args[:id]).to have(3).items
        expect(contact_ids).to include(*args[:id])
      end.and_call_original

...raises a confusing error (NoMethodError: undefined method 'and_call_original' for []:Array). It would be good to fix that as well.

[myronmarston]

In @BjRo's gist, it also came up that an expression like this:

      expect(CachedUser).to receive(:where) do |args|
        expect(args[:id]).to have(3).items
        expect(contact_ids).to include(*args[:id])
      end.and_call_original

...raises a confusing error (NoMethodError: undefined method 'and_call_original' for []:Array). It would be good to fix that as well.

[coveralls]

Changes Unknown when pulling d8bca94 on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling d8bca94 on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling 650bee8 on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling 650bee8 on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling 650bee8 on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling 650bee8 on warn_when_overriding_implementation into * on master*.

[JonRowe]

Ready for a review I guess.

[JonRowe]

Ready for a review I guess.

[xaviershay]

Could final commit be squashed into another?

[xaviershay]

Could final commit be squashed into another?

[xaviershay]

Looks good otherwise when build is green.

[xaviershay]

Looks good otherwise when build is green.

[JonRowe]

It's awaiting rspec/rspec-core#1024 (to sync the warning stuff)

[JonRowe]

It's awaiting rspec/rspec-core#1024 (to sync the warning stuff)

[coveralls]

Changes Unknown when pulling 894dd8b on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling 894dd8b on warn_when_overriding_implementation into * on master*.

[JonRowe]

Actually I think we can merge this now and sync up the warnings stuff later if need be

[JonRowe]

Actually I think we can merge this now and sync up the warnings stuff later if need be

[xaviershay]

good

[xaviershay]

Yeah I don't see a reason to gate this on the core PR. Worst case scenario we just need to come back here and change it again if core PR changes, that's not terrible.

[xaviershay]

Yeah I don't see a reason to gate this on the core PR. Worst case scenario we just need to come back here and change it again if core PR changes, that's not terrible.

[coveralls]

Changes Unknown when pulling 659b039 on warn_when_overriding_implementation into * on master*.

[coveralls]

Changes Unknown when pulling 659b039 on warn_when_overriding_implementation into * on master*.

[myronmarston]

This looks good, but did we address the other odd error (NoMethodError: undefined method 'and_call_original' for []:Array) I mentioned above ?

[myronmarston]

This looks good, but did we address the other odd error (NoMethodError: undefined method 'and_call_original' for []:Array) I mentioned above ?

[JonRowe]

Hmm, no, but thats a block capture issue... e.g.

expect(user).to receive(:where) do |args|
  expect(args[:id].size).to eq 3
end.and_call_original

produces the weird error

expect(user).to( receive(:where) do |args|
  expect(args[:id].size).to eq 3
end.and_call_original )

Works fine.

[JonRowe]

Hmm, no, but thats a block capture issue... e.g.

expect(user).to receive(:where) do |args|
  expect(args[:id].size).to eq 3
end.and_call_original

produces the weird error

expect(user).to( receive(:where) do |args|
  expect(args[:id].size).to eq 3
end.and_call_original )

Works fine.

[myronmarston]

Ah...I know what's going on: that expression passes the block to to due to ruby's precedence rules. So and_call_original is being called from the return value of to. which is the return value of handle_matcher, which returns whatever matcher.matches? returns, which, in this case, is returning @recorded_customizations, which is an array:

rspec-mocks/lib/rspec/mocks/matchers/receive.rb

Lines 76 to 78 in f434af5

	@recorded_customizations.each do |customization|
	customization.playback_onto(expectation)
	end

So, I think if we changed RSpec::Mocks::Matchers::Recive#setup_method_substitute to return expectation, it would allow further chaining. Want to take a stab at writing a failing spec, adding that, and seeing if it passes?

[myronmarston]

Ah...I know what's going on: that expression passes the block to to due to ruby's precedence rules. So and_call_original is being called from the return value of to. which is the return value of handle_matcher, which returns whatever matcher.matches? returns, which, in this case, is returning @recorded_customizations, which is an array:

rspec-mocks/lib/rspec/mocks/matchers/receive.rb

Lines 76 to 78 in f434af5

	@recorded_customizations.each do |customization|
	customization.playback_onto(expectation)
	end

So, I think if we changed RSpec::Mocks::Matchers::Recive#setup_method_substitute to return expectation, it would allow further chaining. Want to take a stab at writing a failing spec, adding that, and seeing if it passes?