Use `is_expected.to` instead of `should` #215

JoelQ · 2014-08-06T20:11:26Z

Even though we've switched to the expect syntax, we've still been using
should for one-liners with an implicit subject. RSpec 3 introduced
is_expected.to as an alternative. Myron Marston explains:

Some users have expressed confusion about how this should relates to the
expect syntax and if you can continue using it. It will continue to be
available in RSpec 3 (again, regardless of your syntax configuration), but
we’ve also added an alternate API that is a bit more consistent with the
expect syntax

From: New API for
one-liners

Even though we've switched to the `expect` syntax, we've still been using `should` for one-liners with an implicit subject. RSpec 3 introduced `is_expected.to` as an alternative. Myron Marston explains: > Some users have expressed confusion about how this should relates to the > expect syntax and if you can continue using it. It will continue to be > available in RSpec 3 (again, regardless of your syntax configuration), but > we’ve also added an alternate API that is a bit more consistent with the > expect syntax From: [New API for one-liners](http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3#new_api_for_oneliners_)

gabebw · 2014-08-06T20:34:30Z

This feels a little bit like change for the sake of change. I don't see any benefits beyond the fact that this has the word expect in it.

calebhearth · 2014-08-06T20:45:23Z

Yeah, it's also a lot longer which I'm against.

JoelQ · 2014-08-06T21:22:05Z

@gabebw I think it's not so much because it has the word expect in it but because it doesn't have the word should which can be confusing since should means two different things in RSpec depending on the context.

jessieay · 2014-08-06T21:53:55Z

I haven't been using is_expected.to for one liners yet, but I like it MUCH more than

it { expect(subject).to be_blah }

that I've seen on a few projects.

mcmire · 2014-08-07T17:35:25Z

I don't mind this change, though it would take getting used to. Personally, should isn't confusing to me, can you elaborate on why you think so? Does it mean two different things?

sikachu · 2014-08-07T17:37:29Z

I actually thought that should for one-liner was deprecated. Seems like it's not?

JoelQ · 2014-08-07T17:45:17Z

@mcmire The following are not the same:

# monkey-patches Object, has been deprecated
# our guides state that we should use expect(subject).to here
it { subject.should be_true }

# doesn't monkey-patch Object, still available in RSpec3
# RSpec3 introduced is_expected.to as an alternative to this
it { should be_true }

calebhearth · 2014-08-07T18:04:43Z

should as a one-liner isn't going away, and I still prefer it to more verbose alternatives.

sikachu · 2014-08-07T18:14:22Z

Since should is not going away, I think let's keep should in one-liner.

mcmire · 2014-08-07T19:17:11Z

@JoelQ Gotcha, yeah, I see your point.

jferris · 2014-09-11T16:00:06Z

@JoelQ still interested in this? Any further opinions here?

JoelQ · 2014-09-11T17:30:45Z

I personally prefer is_expected.to but I'm fine sticking with should if the rest of the team prefers. I'd like to get a few more opinions on this before closing this PR though.

nickrivadeneira · 2014-09-11T17:38:39Z

I prefer is_expected.to. I've used it on a recent project and it feels more consistent with expect(foo).to in other tests.

drapergeek · 2014-09-11T17:38:54Z

I prefer should for one-liners.

joshuaclayton · 2014-09-11T17:39:34Z

I've no opinion, I enjoy the expect-ish consistency and don't personally care about the additional characters per line, but I'm also not so convicted that I'd really argue if everyone wants to continue with should.

derekprior · 2014-09-11T17:51:46Z

As best I can tell, the only reason this method was added was to keep people from continually asking what the one-line equivalent to expect is.

Should is shorter and reads better to me, but I don't feel super strongly about it.

mcmire · 2014-09-11T18:08:46Z

So leaving aside personal preference for a moment, what about people who are new to RSpec (i.e. apprentices), do we feel that is_expected.to makes more sense from that perspective given its similarity to expect(...)?

iancanderson · 2014-09-11T18:09:26Z

I liked is_expected_to because it makes the language more consistent, which has the side-effect of making more sense to beginners, as @mcmire suggested

derekprior · 2014-09-11T18:25:47Z

Good point, @mcmire. I don't think we should let "what's most newbie/community friendly" drive all of our guides but in the face of no real functional arguments for one or the other, I think that's an okay default.

How do we answer this question?

robwise · 2014-09-11T19:07:40Z

A random person's 2 cents: I don't think it's necessary, and any "user-friendliness" is negated by the increased complexity of yet one more "no-no" to remember. Changing the RSpec config to expect the expect syntax should be good enough.

JoelQ · 2014-09-11T19:15:53Z

@robwise Currently the guides explicitly say to use should for one-liners. This PR suggests changing to using is_expected.to.

Are you suggesting that we do neither and have no guideline one what to use for one liners since both should and is_expected.to are valid when RSpec is configured with the expect syntax?

BlakeWilliams · 2014-09-11T19:29:50Z

I'm slightly leaning towards should for one liners. is_expected.to looks a bit weird to me and is also a bit longer, which is something I don't want in a one liner.

robwise · 2014-09-11T19:33:01Z

@JoelQ Well, completely eliminating the rule is actually an interesting idea, considering both are syntaxes are currently valid. Obviously, the invalid .should method syntax would still be disallowed.

But, no, my original suggestion was to keep the guide as-is, thereby allowing should one-liners. Changing the guide to require the is_expected.to syntax just doesn't make a whole bunch of sense to me for length reasons and unnecessary change.

nickrivadeneira · 2014-09-11T19:59:00Z

Based on the documentation of RSpec, it feels like is_expected.to is the intended one-liner syntax when using the expect syntax whereas should might remain for legacy reasons.

is_expected is defined simply as expect(subject) and is designed for when you are using rspec-expectations with its newer expect-based syntax.

should was designed back when rspec-expectations only had a should-based syntax. However, it continues to be available and work even if the :should syntax is disabled (since that merely removes Object#should but this is RSpec::Core::ExampleGroup#should).

robwise · 2014-09-11T23:11:21Z

More insight on that in this comment thread.

jferris · 2014-10-09T17:07:21Z

@JoelQ any updates here?

Previously one-liners could be written in RSpec like: it { should validate_presence_of(:name) } In RSpec 3, the `should` syntax was removed because it monkey-patched `Object`. The one-liner syntax shown above was kept because its `should` did not monkey-patch `Object`. To avoid confusion, RSpec 3 added an `expect`-style way of writing one-liners: it { is_expected.to validate_presence_of(:name) } According to Myron Marston: > Some users have expressed confusion about how this should relates to the > expect syntax and if you can continue using it. It will continue to be > available in RSpec 3 (again, regardless of your syntax configuration), but > we’ve also added an alternate API that is a bit more consistent with the > expect syntax From: [New API for one-liners](http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3#new_api_for_oneliners_) A proposal was made to switch to using the new `is_expected.to` syntaxin [this pull request](#215). However, responses were mixed. Given the lack of consensus one way or the other, let's remove the guideline entirely and let each project decide which syntax to use.

JoelQ · 2014-10-09T17:30:15Z

Given the lack of consensus here, I'm going to close this PR. Feel free to reopen and continue the discussion. I'm also opening #234 to not have a guideline at all on RSpec one-liners.

Previously one-liners could be written in RSpec like: it { should validate_presence_of(:name) } In RSpec 3, the `should` syntax was removed because it monkey-patched `Object`. The one-liner syntax shown above was kept because its `should` did not monkey-patch `Object`. To avoid confusion, RSpec 3 added an `expect`-style way of writing one-liners: it { is_expected.to validate_presence_of(:name) } According to Myron Marston: > Some users have expressed confusion about how this should relates to the > expect syntax and if you can continue using it. It will continue to be > available in RSpec 3 (again, regardless of your syntax configuration), but > we’ve also added an alternate API that is a bit more consistent with the > expect syntax From: [New API for one-liners](http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3#new_api_for_oneliners_) A proposal was made to switch to using the new `is_expected.to` syntaxin [this pull request](#215). However, responses were mixed. Given the lack of consensus one way or the other, let's remove the guideline entirely and let each project decide which syntax to use.

mcmire · 2015-03-26T14:27:36Z

Do we want to revisit this? I'm finding more and more that people who leave issues on shoulda-matchers tend to prefer the is_expected syntax rather than the should syntax. I'm considering switching the README and documentation to use is_expected... but I'm hesitant to do this if we currently promote the use of should.

JoelQ · 2015-03-26T14:39:13Z

We don't promote either form. The guideline was removed in #234. I don't see a problem with converting the shoulda-matchers README to is_expected, although others may disagree.

mcmire · 2015-03-26T15:41:22Z

Oh yeah! It sure was. Cool, thanks.

JoelQ mentioned this pull request Oct 9, 2014

Remove RSpec guideline for one-liners #234

Merged

JoelQ closed this Oct 9, 2014

JoelQ deleted the jq-is-expected branch January 14, 2015 16:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use `is_expected.to` instead of `should` #215

Use `is_expected.to` instead of `should` #215

JoelQ commented Aug 6, 2014

gabebw commented Aug 6, 2014

calebhearth commented Aug 6, 2014

JoelQ commented Aug 6, 2014

jessieay commented Aug 6, 2014

mcmire commented Aug 7, 2014

sikachu commented Aug 7, 2014

JoelQ commented Aug 7, 2014

calebhearth commented Aug 7, 2014

sikachu commented Aug 7, 2014

mcmire commented Aug 7, 2014

jferris commented Sep 11, 2014

JoelQ commented Sep 11, 2014

nickrivadeneira commented Sep 11, 2014

drapergeek commented Sep 11, 2014

joshuaclayton commented Sep 11, 2014

derekprior commented Sep 11, 2014

mcmire commented Sep 11, 2014

iancanderson commented Sep 11, 2014

derekprior commented Sep 11, 2014

robwise commented Sep 11, 2014

JoelQ commented Sep 11, 2014

BlakeWilliams commented Sep 11, 2014

robwise commented Sep 11, 2014

nickrivadeneira commented Sep 11, 2014

robwise commented Sep 11, 2014

jferris commented Oct 9, 2014

JoelQ commented Oct 9, 2014

mcmire commented Mar 26, 2015

JoelQ commented Mar 26, 2015

mcmire commented Mar 26, 2015

Use is_expected.to instead of should #215

Use is_expected.to instead of should #215

Conversation

JoelQ commented Aug 6, 2014

gabebw commented Aug 6, 2014

calebhearth commented Aug 6, 2014

JoelQ commented Aug 6, 2014

jessieay commented Aug 6, 2014

mcmire commented Aug 7, 2014

sikachu commented Aug 7, 2014

JoelQ commented Aug 7, 2014

calebhearth commented Aug 7, 2014

sikachu commented Aug 7, 2014

mcmire commented Aug 7, 2014

jferris commented Sep 11, 2014

JoelQ commented Sep 11, 2014

nickrivadeneira commented Sep 11, 2014

drapergeek commented Sep 11, 2014

joshuaclayton commented Sep 11, 2014

derekprior commented Sep 11, 2014

mcmire commented Sep 11, 2014

iancanderson commented Sep 11, 2014

derekprior commented Sep 11, 2014

robwise commented Sep 11, 2014

JoelQ commented Sep 11, 2014

BlakeWilliams commented Sep 11, 2014

robwise commented Sep 11, 2014

nickrivadeneira commented Sep 11, 2014

robwise commented Sep 11, 2014

jferris commented Oct 9, 2014

JoelQ commented Oct 9, 2014

mcmire commented Mar 26, 2015

JoelQ commented Mar 26, 2015

mcmire commented Mar 26, 2015

Use `is_expected.to` instead of `should` #215

Use `is_expected.to` instead of `should` #215