webrat required, but no gem dependency

[ultrasaurus]

With a very simple, newbie sequence of steps:
http://blazingcloud.net/2010/09/19/rails-3-getting-started/
I get errors after generate scaffold then rake spec:
/Users/sarah/.rvm/rubies/ruby-1.8.7-p302/bin/ruby -S bundle exec rspec "./spec/controllers/notes_controller_spec.rb" "./spec/helpers/notes_helper_spec.rb" "./spec/models/note_spec.rb" "./spec/requests/notes_spec.rb" "./spec/routing/notes_routing_spec.rb" "./spec/views/notes/edit.html.erb_spec.rb" "./spec/views/notes/index.html.erb_spec.rb" "./spec/views/notes/new.html.erb_spec.rb" "./spec/views/notes/show.html.erb_spec.rb"
...............**........FFFF

Pending:
  :

Failures:
  1) notes/edit.html.erb renders the edit note form
    Failure/Error: rendered.should have_selector("form", :action => note_path(@note), :method => "post") do |form|
    undefined method `has_selector?' for #<String:0x1034ecfb0>
    # ./spec/views/notes/edit.html.erb_spec.rb:15
    # /Users/sarah/.rvm/gems/ruby-1.8.7-p302@rails3/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:239:in `inject'

  2) notes/index.html.erb renders a list of notes
    Failure/Error: rendered.should have_selector("tr>td", :content => "Title".to_s, :count => 2)
      :

Finished in 0.32394 seconds
29 examples, 4 failures, 2 pending
rake aborted!
Command failed with status (1): [/Users/sarah/.rvm/rubies/ruby-1.8.7-p302/b...]

If webrat is required, it should be installed when the gem is installed, right?

There is a simple enough workaround, but it took me some digging to figure out.

[dchelimsky]

The generators work with webrat, but you're not required to use it. This is documented in the README.

[ultrasaurus]

I'm updating my blog post, so adding steps to repro the issue here:

$ rvm install 1.9.2
$ rvm use 1.9.2
$ rvm gemset create rails3
$ rvm use 1.9.2@rails3
$ rails new myapp
$ cd myapp
$ echo "rvm use 1.9.2@rails3" >> .rvmrc
$ vi Gemfile

group :development, :test do
  gem 'sqlite3-ruby', :require => 'sqlite3'
  gem "rspec-rails", ">= 2.0.0.beta.22"
end

$ bundle install
$ rails generate rspec:install   
$ rails generate scaffold note title:string content:text
$ rake db:migrate
$ rake spec

[dchelimsky]

How about:

group :development, :test do
  gem 'sqlite3-ruby', :require => 'sqlite3'
  gem "rspec-rails", ">= 2.0.0.beta.22"
  gem "webrat", ">= 0.7.2.beta.1"
end

[ultrasaurus]

My point is that rspec should be newbie friendly. Here are a couple of options:

• don't generate view specs if webrat is not installed, providing a solution message like: view specs not generated. If you want view specs, please add "gem 'webrat'" to your Gemfile and then run the "bundle install" and generate commands again.
• in the README, call out the alternate configuration at the top. As written, it requires you to know and think about the fact that scaffold generator creates view specs. Why would I assume that rspec generates specs I can't use?

I prefer the former.

[dchelimsky]

How about generating empty view specs (a la the model specs) with that messaging in the view specs rather than on the command line? More persistent that way (the message, that is).

[ultrasaurus]

I prefer specs that pass but actually test something (a la rspec v1 generated model specs). What about having the view specs be empty with a comment if neither webrat or capybara is installed, and then generating specs with the right syntax? or better yet, make it so the rspec matchers will work with either. It looks like "should contain" could be supported by both and I think it is good practice to not depend on specific tags in your view specs anyhow.

What do you think? If you are open to change in this area, I could noodle around with some ideas in a fork.

[dchelimsky]

Unfortunately, Capybara matchers don't support view specs right now [1]. If/when that changes we can re-visit, but for now we can leave that out of the equation.

I think the most appealing option for me is what you suggested a couple of comments back: if webrat is present, generate a passing spec. if not, generate a pending spec with helpful comments. If you'd like to make that work, awesome! If not, I'll get to it soon.

[1] http://github.com/jnicklas/capybara/issues#issue/139

[ultrasaurus]

Capybara's README says:

You can these use with RSpec’s magic matchers:

page.should have_xpath('//table/tr')
page.should have_css('table tr.foo')
page.should have_content('foo')

Are have_css and have_xpath broken with Rails 3? or is the README misleading and they aren't planned to work? In any case, we could just use have_content and I think it would work nicely.

[dchelimsky]

Those work in Cucumber or in RSpec controller specs because the page object is a Capybara session. View specs don't work that way. So yes, the Capybara README is incomplete in that respect.

[dchelimsky]

Fixed: 800a564

I added a --webrat-matchers flag to the scaffold generator. Without it, it uses assert_select and stock rspec matchers, and adds a comment to the generated spec suggesting use of --webrat-matchers

At the point that capybara works with view specs, I'll be happy to add the same for capy