Expect vs Should syntax about betterspecs HOT 14 CLOSED

I agree that expect is the correct syntax to use for block expectations, but for one-liners, it's actually still perfectly okay to use should, as it's a method from a different class entirely (it's not the same should) and it sounds and looks much better than it { is_expected.to ... }. The only reason the other should was removed was because it required monkey-patching Object. That is not the case with this should, and it has not been removed as of RSpec 3.4, and doesn't look like it will be.

I think both syntaxes for one-liners should be on the "GOOD" list.

from betterspecs.

+1 at @mltsy's point. Are we crossing wires here? I feel like should reads a lot better than is_expected.to in one-liner cases.

from betterspecs.

I’m sorry for being blunt here, but I think this whole expect vs should is horse shit.

Why remove should? It means the same thing. There is a reason we have synonyms in English language.

I love should and use it and will keep using it. And when 4 removes it I will add an alias.

This is dumb stupid religious dog fighting. Why not have it both ways?

from betterspecs.

+1

expect syntax is mature. Given that should is deprecated in 3, and removed from 4, I would recommend switching all the documentation to use expect by default, and then adding an "expect vs should" section. It's a waste for brand new rspec users to learn a syntax that's going away when the new syntax is available today.

from betterspecs.

👍

from betterspecs.

If expect is to be used instead of should, can the other examples be updated to reflect that? :)

e.g. the "Use contexts" guideline...

from betterspecs.

@jguice all examples are now using the expect syntax.

The context guideline, and all one-liner syntax(with implicit subject) still use the should syntax. More info about it here on a answer of Stack Overflow by Myron

from betterspecs.

Ah! I think what is confusing in the contexts example is that, when going from BAD to GOOD, not only is the context added but the "it" is changed to a one-liner which also makes the "expect" become a "should". It seems like the only changes from a BAD example to a GOOD example should be directly related to the particular guideline being illustrated for maximum clarity ;)

Also adding a note to the Expect vs. Should guideline about the one-line format still (acceptably) using should might be helpful.

I found a minor typo on Expect vs. Should too: "Configure the Rspec to only accept the new syntax on new projects, to avoid have the 2 syntax all over the place." (the "have" should be a "having").

Let me know if I should create a pull request or new issue for these :)

from betterspecs.

@jguice I like the idea of have a note on Expect vs. Should section. Something like:

In one line expects or with implicit subject we still use the should syntax, since is no change here on new syntax

And add the link to Myron answer on Stack Overflow.

from betterspecs.

If you find the time guys, would be perfect to add this little note.

from betterspecs.

By the way, for people who are willing to maintain existing should syntax specs, I'd like to recommend converting them to expect syntax by using Transpec.

from betterspecs.

Done in here #91

from betterspecs.

@kigster do you have any guidance on how to set an alias when it is officially removed? I am a little lost as to how to maintain should syntax.

from betterspecs.

Since these are likely simple methods you can just alias them like this, say in ruby:

  def alias(...)
     original(*, **, &block)
  end

But I don't think you need to worry about it. It's ok to break the API as long you increment the major version and document it in the CHANGELOG.

from betterspecs.