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

Merged
merged 1 commit into from Apr 2, 2014

Projects

None yet

4 participants

@twalpole
Collaborator

@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
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?

@twalpole
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.

@myronmarston
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.

@twalpole
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.

@twalpole
Collaborator

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

@myronmarston
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
@abotalov abotalov commented on the diff Apr 1, 2014
gemfiles/Gemfile.base-versions
@@ -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'
@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 and 1 other commented on an outdated diff Apr 1, 2014
capybara.gemspec
@@ -30,10 +30,10 @@ Gem::Specification.new do |s|
s.add_development_dependency("selenium-webdriver", ["~> 2.0"])
s.add_development_dependency("sinatra", [">= 0.9.4"])
- s.add_development_dependency("rspec", [">= 2.2.0"])
+ s.add_development_dependency("rspec", [">= 3.0.0.beta2"])
@abotalov
abotalov Apr 1, 2014 Collaborator

Gemfile.base-versions tests Capybara against 2.2.0. Thus it seems there's no need to do this change.

@twalpole
twalpole Apr 1, 2014 Collaborator

Without this change the tests wouldnt be run against the 3.0 beta to show the issues that are coming from 3.0 - the base-versions gemfile is run separately in the tests

@abotalov abotalov and 1 other commented on an outdated diff Apr 1, 2014
lib/capybara/rspec.rb
@@ -4,6 +4,15 @@
require 'capybara/rspec/matchers'
require 'capybara/rspec/features'
+# Alias be_truthy/be_falsey if not already defined to be able to use in RSpec 2 and 3
@abotalov
abotalov Apr 1, 2014 Collaborator

It seems that aliasing is used only in Capybara's own specs. Thus I think this code should be placed somewhere in spec folder (I haven't looked yet where it can be placed).

I think it's a bit strange that if a user uses RSpec 2.14.5 he will get be_truthy undefined if he doesn't require 'capybara/rspec' but defined if he does require 'capybara/rspec'

@twalpole
twalpole Apr 1, 2014 Collaborator

Actually this does need to be in the lib folder since it needs to be available for third party driver tests if they are testing with rspec 2 - however I think it should have been in lib/capybara/spec/spec_helper.rb so I've moved it there

@abotalov abotalov and 1 other commented on an outdated diff Apr 1, 2014
spec/rspec/features_spec.rb
@@ -5,48 +5,53 @@
@in_filtered_hook = true
end
-feature "Capybara's feature DSL" do
+feature "Capybara's feature DSL", tw: true do
@abotalov
abotalov Apr 1, 2014 Collaborator

Did you mean :twalpole? 😉

@twalpole
twalpole Apr 1, 2014 Collaborator

this is a leftover mistake removing now.

@abotalov abotalov and 1 other commented on an outdated diff Apr 1, 2014
spec/rspec/features_spec.rb
end
end
+
+fetch_current_example = RSpec.respond_to?(:current_example) ?
@abotalov
abotalov Apr 1, 2014 Collaborator

Is fetch_current_example used?

@twalpole
twalpole Apr 1, 2014 Collaborator

Yes - about 12 lines below where its defined

@abotalov
abotalov Apr 1, 2014 Collaborator

@twalpole I think you meant lib/capybara/rspec.rb when you wrote that comment. Yes, it's used in rspec.rb.

But my comment is about the file I commented on - spec/rspec/features_spec.rb. fetch_current_example doesn't seem to be used in this file as it's the last line in the file.

@twalpole
twalpole Apr 1, 2014 Collaborator

@abotalov whoops -- good catch

@twalpole
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
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
Collaborator
abotalov commented Apr 1, 2014

LGTM

@twalpole
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

@twalpole twalpole 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
ba37f78
@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