Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Document changes for Rspec3 #777

Closed
jcarres-mdsol opened this Issue · 10 comments

5 participants

Jordi Polo Carres Myron Marston Bradley Schaefer Jon Rowe Sam Phippen
Jordi Polo Carres

I guess there is still not even a branch for Rspec 3 but if there is a list of things that will get deprecated it will be very helpful to know about them early.
Even a list on a .md file will be helpful.
For instance, I just saw in a closed issue that 'its' will get deprecated. I was just adding 'its' to some of my specs...

Maybe what I really want to know is from all the possible ways of writing specs which are going to be reinforced in the future and which are going to get deprecated so I can start getting use to it now.

Myron Marston

This request makes sense. I'm concerned about the extra effort it'll take to maintain a document like this; one of us may create it at one point, but it's likely to get out-of-date. If someone from the community wanted to volunteer to make such a list and keep it up to date, I'd heartily support that, though :). (Any takers?)

I will say that even though we haven't started on RSpec 3 yet, our plans from some internal discussions are to make the upgrade as painless as possible. For any features that we do remove from rspec-core (such as its), we'll make sure there's an rspec extension gem that provides the feature so you can continue to use it. And honestly, at the moment I can't think of any other features that would be put on such a list besides its.

Jordi Polo Carres

If the only feature to go away so far is 'its' then we do not need a document with one line.
I guess what I am looking for is something betterspecs.org but written by the developers of rspec.
I think the list in fact would be quite short:

  • Do not use its, will be deprecated.
  • Use expect{} instead of .should (I think .should will be deprecated?)
  • Use let, subject instead of before blocks because of the lazy evaluation, etc.

That's about it

Bradley Schaefer
Collaborator

What happens to implicit it { should be_valid } style blocks without should? Or does that still work because should doesn't need to hang on every Object there?

Myron Marston

If the only feature to go away so far is 'its' then we do not need a document with one line.

Thinking about this a bit more, there are some other things going away. But the vast majority of them have already been deprecated and they print warnings when you use them. Beyond that, here are a few other things:

  • We plan to drop 1.8.6 and 1.9.1 support
  • We plan to remove rcov support (or potentially put it into another gem)
  • We plan to move autotest support into another gem (probably rspec-autotest)
  • We're discussing moving the textmate formatter into the textmate bundle
  • We've discussed deprecating before(:all) (see #573) but no decisions have been made

I think .should will be deprecated?

We have no plans to deprecate or remove .should. We're discussing changing the default configuration in RSpec 3 so that .should is disabled by default.

I guess what I am looking for is something betterspecs.org but written by the developers of rspec.

FWIW, I've commented on many of the bettespecs recommendations on their github issues tracker (example) but the site itself hasn't been changed since it launched as far as I know, which is frustrating. I personally don't have the UI skills to make a decent similar site, or the time to do so.

What happens to implicit it { should be_valid } style blocks without should? Or does that still work because should doesn't need to hang on every Object there?

Rather than repeating myself, please read:

Bradley Schaefer
Collaborator

@myronmarston Thanks for the links, they completely answer my question and then some.

Jon Rowe
Owner

This is something we should be doing as we go through the changes for RSpec 3. I think it may well be worth a seperate file or page on the wiki, as we'll be able to use it as a base internally for docs later on... Thoughts?

Myron Marston
Sam Phippen
Collaborator

I think I'm going to close this with a view to the fact that @myronmarston is working on a big document that has all the important stuff in it.

Sam Phippen samphippen closed this
Jon Rowe
Owner

We could use that as the source of what we're working on but wouldn't it still be a good idea to have something in the source?

Sam Phippen
Collaborator

I guess we also have the changelog that we're maintaining. I suppose once we've got 3.0.0 nearly ready to go we can build an updating guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.