is_expected with block expectations

[xaviershay]

The following situation just confused someone here at work:

describe 'is_expected with block expectation' do
  subject { raise }

  it { is_expected.to raise_error }
end

That reads like it should work, but doesn't because is_expected is defined as expect(subject).

I don't typically use is_expected, so not sure if there is a canonical way to do this already. It isn't listed at https://www.relishapp.com/rspec/rspec-core/docs/subject/one-liner-syntax

1. Is there a "correct way" to do this?
2. Is one-liner syntax something that we (as a core team) use much, or is it in the expect_any_instance_of bucket of extras?
3. Should we add one-liner Relish documentation about using block matchers? I'm thinking yes.
4. Is there a way to fix this transparently, and if yes, should we? My gut says no because it would be switching is_expected implementation based on matcher used and that seems gnarly.

Tangentially related discussion thread on separating block vs value expectations, in which we didn't discuss this case: #526

cc @rspec/rspec

[JonRowe]

1. Is there a "correct way" to do this?

Not with the one liner syntax that I'm aware of.

1. Is one-liner syntax something that we (as a core team) use much, or is it in the expect_any_instance_of bucket of extras?

It's in the same bucket, I certainly don't recommend it.

1. Should we add one-liner Relish documentation about using block matchers? I'm thinking yes.

We should mention they're not supported.

1. Is there a way to fix this transparently, and if yes, should we? My gut says no because it would be switching is_expected implementation based on matcher used and that seems gnarly.

this has come up before and we shied away from it because the only way to really do it is to pass a block out of the subject block and then conditionally detect what to do with it, the last conversation we had around this resulted in the original issue raiser producing https://github.com/puyo/rspec-subject_call

[myronmarston]

Not with the one liner syntax that I'm aware of.

There is, if you're willing to make your subject a lambda:

describe 'is_expected with block expectation' do
  subject { -> { raise } }

  it { is_expected.to raise_error }
end

...that's pretty obtuse and not something I'd recommend, generally.

Is one-liner syntax something that we (as a core team) use much, or is it in the expect_any_instance_of bucket of extras?

I consider it in between. It's not something I use frequently, and it's an often abused feature of RSpec...but it's not generally problematic the way expect_any_instance_of is, and there are situations where it works really, really well. I think mustermann has a great example of its usage (although it's using the older should one-liner syntax, but I consider them interchangable). I think for a case like mustermann's, you want the details of the exact string you are matching against to be included in the doc output (as coming up with prose descriptions for all those would be tricky and more ambiguous). Letting the matcher generate the description for the example keeps them in sync, ensuring you don't wind up with doc strings that "lie" like comments can, which can lead to other problems.

Should we add one-liner Relish documentation about using block matchers? I'm thinking yes.

We should mention they're not supported.

Agreed.

Is there a way to fix this transparently, and if yes, should we? My gut says no because it would be switching is_expected implementation based on matcher used and that seems gnarly.

I think the complexity to doing such a thing would be greater than the benefit. I also think it's good for people to understand that the expectation is being set on a lambda/proc that wraps an expression, and not on the return value of the expression itself. Any attempt to make this work nicely would hide that distinction which would only lead to more confusion.

Also, you'll generally get warnings from RSpec 3 when you attempt to use a block matcher against a non-block subject. That falls over for raise_error, unfortunately, because in an expression like expect(raise).to raise_error ruby evaluates the raise first and it aborts before RSpec even has a chance to do anything with it.

[xaviershay]

For the mustermann-style case, I tend to use a custom method: https://github.com/xaviershay/pacebot/blob/master/spec/parse_spec.rb#L23 ... but then I'm the kind of heathen that tends to like assert methods :P

I'll put together a doc PR.

[myronmarston]

but then I'm the kind of heathen that tends to like assert methods :P

😱

[xaviershay]

I obviously haven't done this. I may still, but am relaxing the commitment expressed in my prior comment.

[codesnik]

if is_expected would be defined as

def is_expected
   expect { subject }
end

( using { } instead of ( )) then it should work. Also will help with is_expected.to change when subject is a method call with side effects, and it would make "unit specs" with a lot of describe "#method" do sections much shorter, while mantaining readability.

But it could slow down a little every is_expected call. Any other reasons, why it wasn't done in that way?

[myronmarston]

Any other reasons, why it wasn't done in that way?

The reason is that expect { subject } only works with block expectations. Non-block expectations (e.g. eq, include, be_within, be <, etc) can only be used off of expect(object), not expect { object }. There're a few reasons for that:

• The generic expect {}.to matcher machinery does not evaluate the block -- instead the block is passed to the matcher so the matcher can evaluate it. For this block matchers, this is important because the matcher must "wrap" evaluation of the block with special logic (such as rescuing an error, etc).
• That means that if you tried expect { 5 }.to eq(5), the eq matcher would receive proc { 5 } as an argument to match against 5. The eq matcher checks == of the two arguments. proc { 5 } == 5 is obviously not true so it won't match.
• Procs are objects, too, which means that it's completely valid for eq to compare two proc objects for equality -- which in turn means that eq can't safely evaluate a proc if that's what it's given.

See #526 for more background and info on this.

[mrageh]

@xaviershay and @myronmarston what's the status of this issue?

[myronmarston]

The consensus is to improve the documentation around this but no one has taken that on yet. Would you like to?

[mrageh]

yup @myronmarston I'll do that during this upcoming week

[mrageh]

I think we can close this PR as the docs around the one-liner syntax has been improved

[singpolyma]

Could maybe add a is_expected_block syntax for this?