Allow Capybara 3.x

[twalpole]

Summary

Capybara 3.0.0.rc1 has been released, and contains no changes that affect how Rails system tests integrate with it.

This PR allows Rails users to use Capybara 3.x. Would be great to have it backported to Rails 5.1 and 5.2 too

[rails-bot]

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

[jeremy]

https://github.com/teamcapybara/capybara/blob/master/History.md#version-300rc1 for reference

[rafaelfranca]

We also need to update the Gemfiles.

[twalpole]

@rafaelfranca Technically the Gemfiles dont need to be updated - It's only this file that would prevent a user from changing the restriction in their projects Gemfile to allow Capybara 3.x.

[jeremy]

If we upgrade the version of Capybara we allow, then we test against it also. Technically :)

[twalpole]

@jeremy Then wouldn't it be required to test against multiple versions? The rails test suite doesn't appear to be set up to do that.

[rafaelfranca]

No. We will only test with the latest released version version. We also need to update the generated Gemfile otherwise new apps will not allow Capybara 3.0 by default.

[twalpole]

@rafaelfranca Ok - updated version restrictions in Gemfiles too.

[twalpole]

@jeremy Will you backport these changes to 5.1_stable and 5.2_stable or do I need to file separate PRs against those branches?

[jeremy]

Backported to 5-2-stable @ db5a159 since it's still a release candidate. (Stable branches only get bugfixes and security patches, otherwise.)

[twalpole]

@jeremy I understand the policy with regards to 5.1 stable - however I think it may need to be reconsidered for Capybara. The benefit of system testing is to ensure compatibility with browsers, and with most browsers now auto-updating that means compatibility with the latest version of browsers. This means this will be the first gem rails depends on that loses functionality over time because a rails 5.1 app developer won't be able to upgrade Capybara (without upgrading rails) and will therefore lose the ability to test with the latest versions of browsers.

IMHO this would have been much better if the line in actionpack/lib/action_dispatch/system_test_case.rb was just

gem "capybara"

and the version restriction was enforced through the Gemfiles since then an end user could at least override it if necessary, however that was shot down previously (when 5.1 was being released).

[vipulnsward]

Facing this issue right now. I have an App recently migrated to 5.1. Upgrading to 5.2 is big task due to many changes involved.

Not being able to have 3.x capybara, holds back on using headless chrome, etc in a proper way without having to have workarounds.

[twalpole]

@vipulnsward This was added to 5.1 in April -b1b0a33 - but there hasn't been a 5.1.x release that includes it yet -- You can use Rails from the 5-1-stable branch if you need the fix today.

[ericboehs]

It would be nice if we had semi-annual releases of supported Rails versions.