New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes required to get rid of deprecation warnings with rspec 2.99/3.0 #1192

Merged
merged 1 commit into from Apr 2, 2014

Conversation

Projects
None yet
4 participants
@twalpole
Collaborator

twalpole commented Nov 15, 2013

@jnicklas - This is all the tests changed to use 'expect' syntax and changes made to get rid of all the deprecation warnings rspec 2.99.0.beta1 throws in advance of rspec 3 being released. The downside to these changes is that the tests will no longer run with earlier rspecs than 2.99 due to the lack of the be_truthy/be_falsey matchers. I'm not sure that its going to be possible to have tests that can ruin using either rspec 2.x or 3 without implementing our own be_truthy/be_falsey matchers if rspec doesnt have them. Do you think this is worth continuing on currently?

@jnicklas

This comment has been minimized.

Show comment
Hide comment
@jnicklas

jnicklas Nov 15, 2013

Collaborator

Crazy pull request :) Let's maybe hold off until RSpec 3 is released though, and then move the whole suite to 3 in one fell swoop?

Collaborator

jnicklas commented Nov 15, 2013

Crazy pull request :) Let's maybe hold off until RSpec 3 is released though, and then move the whole suite to 3 in one fell swoop?

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Nov 15, 2013

Collaborator

Yeah, I'm fine with that -- most of this was automated conversion with transpec - I did it to see what was coming up and any issues there would be -- it shows that enabling the specs run by other adapters to work in both rspec 2 ( < 2.99) and 3 is going to run into the issue with be_falsey and be_truthy - so we're either going to have to require all other adapters to update to rspec 3 too or work around the issue.

Collaborator

twalpole commented Nov 15, 2013

Yeah, I'm fine with that -- most of this was automated conversion with transpec - I did it to see what was coming up and any issues there would be -- it shows that enabling the specs run by other adapters to work in both rspec 2 ( < 2.99) and 3 is going to run into the issue with be_falsey and be_truthy - so we're either going to have to require all other adapters to update to rspec 3 too or work around the issue.

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Nov 25, 2013

Contributor

If you run into any complications with upgrading, please ping me or one of the other rspec-core folks. We're working hard to make the transition to 3.0 as smooth as possible in spite of the many changes we're making.

Contributor

myronmarston commented Nov 25, 2013

If you run into any complications with upgrading, please ping me or one of the other rspec-core folks. We're working hard to make the transition to 3.0 as smooth as possible in spite of the many changes we're making.

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Nov 25, 2013

Collaborator

@myronmarston a 2.14 release that adds the be_truthy/falsey matchers might be a nice help for tools like capybara that have test suites other project use to ensure compliance and would like to be runnable under rspec 2 and 3.

Collaborator

twalpole commented Nov 25, 2013

@myronmarston a 2.14 release that adds the be_truthy/falsey matchers might be a nice help for tools like capybara that have test suites other project use to ensure compliance and would like to be runnable under rspec 2 and 3.

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Nov 25, 2013

Collaborator

@myronmarston or maybe a separate gem that provides those two matchers

Collaborator

twalpole commented Nov 25, 2013

@myronmarston or maybe a separate gem that provides those two matchers

@myronmarston

This comment has been minimized.

Show comment
Hide comment
@myronmarston

myronmarston Nov 25, 2013

Contributor

Hmm, in 2.14 it's as simple as alias be_truthy be_true; alias be_falsey be_false, but as that's a new API I don't think we can add it in a 2.14.x release without violating SemVer. It's in 2.99 so it's already in an RSpec 2.x release. Also, are all adapters running RSpec 2.14? If not, it wouldn't fix the issue, anyway.

Instead, I'd recommend capybara defining be_truthy and be_falsey aliases if and only if those matchers are not defined...then capybara can use them, and it should work with adapters running any 2.x or 3.x version of RSpec.

unless RSpec::Matchers.method_defined?(:be_truthy)
  RSpec::Matchers.module_eval do
    alias be_truthy be_true
    alias be_falsey be_false
  end
end
Contributor

myronmarston commented Nov 25, 2013

Hmm, in 2.14 it's as simple as alias be_truthy be_true; alias be_falsey be_false, but as that's a new API I don't think we can add it in a 2.14.x release without violating SemVer. It's in 2.99 so it's already in an RSpec 2.x release. Also, are all adapters running RSpec 2.14? If not, it wouldn't fix the issue, anyway.

Instead, I'd recommend capybara defining be_truthy and be_falsey aliases if and only if those matchers are not defined...then capybara can use them, and it should work with adapters running any 2.x or 3.x version of RSpec.

unless RSpec::Matchers.method_defined?(:be_truthy)
  RSpec::Matchers.module_eval do
    alias be_truthy be_true
    alias be_falsey be_false
  end
end
@@ -9,6 +9,7 @@ gem 'rack', '= 1.3.0' # cannot go lower because referer tests need aa7ce77cd0
gem 'rack-test', '= 0.5.4'
gem 'nokogiri', '= 1.3.3'
gem 'rspec', '= 2.2.0'
gem 'fuubar', '>= 0.0.1'

This comment has been minimized.

@abotalov

abotalov Apr 1, 2014

Collaborator

The development_dependency is set to >= 2.0.0 but Gemfile.base-versions sets it to >= 0.0.1.

Also I think Gemfile.base-versions should test against the minimum supported version. Thus I think it's better to define a version using =.

@abotalov

abotalov Apr 1, 2014

Collaborator

The development_dependency is set to >= 2.0.0 but Gemfile.base-versions sets it to >= 0.0.1.

Also I think Gemfile.base-versions should test against the minimum supported version. Thus I think it's better to define a version using =.

Show outdated Hide outdated capybara.gemspec Outdated
Show outdated Hide outdated lib/capybara/rspec.rb Outdated
Show outdated Hide outdated spec/rspec/features_spec.rb Outdated
Show outdated Hide outdated spec/rspec/features_spec.rb Outdated
@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Apr 1, 2014

Collaborator

@abotalov 5 months ago when this PR was first started it was against 2.99 - since then the release of 3 is much closer and so now its testing against the beta of 3 - the base versions is set to rspec 2.2 and whatever the latest version of fuubar is compatible with that is.

Collaborator

twalpole commented Apr 1, 2014

@abotalov 5 months ago when this PR was first started it was against 2.99 - since then the release of 3 is much closer and so now its testing against the beta of 3 - the base versions is set to rspec 2.2 and whatever the latest version of fuubar is compatible with that is.

@abotalov abotalov changed the title from Changes required to get rid of deprecation warnings with rspec 2.99.beta1 to Changes required to get rid of deprecation warnings with rspec 2.99/3.0 Apr 1, 2014

@abotalov

This comment has been minimized.

Show comment
Hide comment
@abotalov

abotalov Apr 1, 2014

Collaborator

Also I noticed that RSpec 2.2 specifies other RSpec libraries using ~> (see https://github.com/rspec/rspec/blob/v2.2.0/rspec.gemspec#L27). Because of it Capybara's Gemfile.base-versions build actually uses RSpec 2.14, not 2.2 (https://travis-ci.org/jnicklas/capybara/jobs/21961445#L277) and will use 2.99 when it will be released.

I think it's not good as 2.99 will contain many features not present in 2.2 and we should build against 2.2 instead (or bump version requirement).

If you think it's out of scope of this PR I can make a new one.

Collaborator

abotalov commented Apr 1, 2014

Also I noticed that RSpec 2.2 specifies other RSpec libraries using ~> (see https://github.com/rspec/rspec/blob/v2.2.0/rspec.gemspec#L27). Because of it Capybara's Gemfile.base-versions build actually uses RSpec 2.14, not 2.2 (https://travis-ci.org/jnicklas/capybara/jobs/21961445#L277) and will use 2.99 when it will be released.

I think it's not good as 2.99 will contain many features not present in 2.2 and we should build against 2.2 instead (or bump version requirement).

If you think it's out of scope of this PR I can make a new one.

@abotalov

This comment has been minimized.

Show comment
Hide comment
@abotalov

abotalov Apr 1, 2014

Collaborator

LGTM

Collaborator

abotalov commented Apr 1, 2014

LGTM

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Apr 1, 2014

Collaborator

@abotalov Yeah I had noticed the rspec 2.2 vs 2.14 issue too (I think I mentioned it another issue somewhere) -- I'm not sure if going back to 2.2 makes any sense at this point - it was released 4.5 years ago and if anyone is still using 2.2 they're probably not updating capybara -- I think testing against 2.14 and 3 is probably going to be fine in the future

Collaborator

twalpole commented Apr 1, 2014

@abotalov Yeah I had noticed the rspec 2.2 vs 2.14 issue too (I think I mentioned it another issue somewhere) -- I'm not sure if going back to 2.2 makes any sense at this point - it was released 4.5 years ago and if anyone is still using 2.2 they're probably not updating capybara -- I think testing against 2.14 and 3 is probably going to be fine in the future

Update all tests to "expect" format and add support for RSpec 3 usage
Swap from :skip to :capybara_skip since :skip is now used by RSpec 3
Add rspec 3 testing to beta gemfile

twalpole added a commit that referenced this pull request Apr 2, 2014

Merge pull request #1192 from twalpole/rspec299
Update all tests to "expect" format and add support for testing drivers with RSpec 2 or the upcoming RSpec 3

@twalpole twalpole merged commit 12b975d into teamcapybara:master Apr 2, 2014

1 check failed

default The Travis CI build could not complete due to an error
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment