let users choose between capybara and webrat about rspec-rails HOT 15 CLOSED

Yea!! However, I believe that capybara and webrat are merging so I wouldn't place this as a top priority.

from rspec-rails.

doesnt look like the merge is happening all that fast. maybe its better to swap over to just swap over to capybara as the default?

from rspec-rails.

I'll make it configurable, but webrat will remain the default for now.

from rspec-rails.

David are you working on this? If not, I can give it a shot.

from rspec-rails.

I'm not. What I'm thinking is that we simply remove the dependency from the gemspec and wrap all the include Webrat::XXX statements in a check for Webrat. Maybe a small helper method so we don't have to say if defined everywhere:

webrat do
  include Webrat::XXX
end

WDYT?

from rspec-rails.

Then we can add the same for Capybara, btw.

from rspec-rails.

Patch: http://github.com/justinko/rspec-rails/tree/issue-49

Another option would be RSpec::Rails.webrat do ...

But I thought include RSpec::Rails::BrowserSimulators; webrat do ... was cleaner.

from rspec-rails.

Hey Justin - that looks good. Do me a favor and either add the includes necessary for Capybara or remove the capybara method and we're good to go (I'd rather not have it 1/2 way there).

from rspec-rails.

Capybara includes added: http://github.com/justinko/rspec-rails/tree/issue-49

from rspec-rails.

Hey Justin - after merging your branch, when I put capybara in the Gemfile instead of webrat, I get this:

uninitialized constant Capybara::Node::Finders

from rspec-rails.

New commit with comments: http://github.com/justinko/rspec-rails/commit/e5e794c4f5b013

from rspec-rails.

I merged this to a branch and added some additional changes/info in an another commit:

http://github.com/rspec/rspec-rails/tree/issue-49

As of now there's no way that I can see to get all the capybara expectations to work in view and helper specs. I don't want to merge this to master until that is resolved. I have an email out to Jonas (capybara's author) for some help. In the mean time, feel free to see if you can get it to work without any major surgery. The goal is to be able to use should have_xpath, should have_css, etc, in view and helper specs.

from rspec-rails.

I heard back from Jonas and he doesn't think there's a good way to support matchers in view and helper specs right now. This might get resolved in the near-ish future, but for now I'm thinking we just don't include capybara in view/helper specs and document that it only works for request/controller specs. WDYT?

from rspec-rails.

Given a.) Most developers spec requests/controllers much more often than views/helpers (if at all) and b.) The rise in popularity of Capybara, I think it would be a good idea to go with your suggestion. Feel free to finish out this issue.

from rspec-rails.

Fixed: http://github.com/rspec/rspec-rails/commit/d4ff873441cad75e9dd6e7dd1dfccf532bb4febf

from rspec-rails.