Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Document changes for Rspec3 #777

Closed
jcarres-mdsol opened this Issue Jan 26, 2013 · 10 comments

Comments

Projects
None yet
5 participants
Contributor

jcarres-mdsol commented Jan 26, 2013

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.

Owner

myronmarston commented Jan 26, 2013

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.

Contributor

jcarres-mdsol commented Jan 26, 2013

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

Member

soulcutter commented Jan 26, 2013

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?

Owner

myronmarston commented Jan 26, 2013

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:

Member

soulcutter commented Jan 26, 2013

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

Owner

JonRowe commented Apr 16, 2013

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?

Owner

myronmarston commented Apr 16, 2013

I think it's a great idea. However, rather than putting it on the wiki
page, and then migrating that to something in source, let's just start with
putting it in source. Maybe we can clear the updating.md and start it
fresh with updating instructions for rspec 3?

On Mon, Apr 15, 2013 at 9:06 PM, Jon Rowe notifications@github.com wrote:

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?


Reply to this email directly or view it on GitHubhttps://github.com/rspec/rspec-core/issues/777#issuecomment-16425566
.

Owner

samphippen commented Jun 4, 2013

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.

@samphippen samphippen closed this Jun 4, 2013

Owner

JonRowe commented Jun 5, 2013

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?

Owner

samphippen commented Jun 5, 2013

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