1
0
Fork 0
mirror of https://github.com/teamcapybara/capybara.git synced 2022-11-09 12:08:07 -05:00

Merge pull request #577 from joliss/doc

Remove extraneous details for the sake of brevity
This commit is contained in:
Jonas Nicklas 2011-12-21 08:03:12 -08:00
commit 897655c25d

View file

@ -106,21 +106,11 @@ You can now write your specs like so:
end
end
Capybara is only included in example groups tagged with
<tt>:type => :request</tt> (or <tt>:acceptance</tt> for compatibility with Steak).
If you are using Rails, put your Capybara specs in <tt>spec/requests</tt> or
<tt>spec/integration</tt>.
If you are testing a Rails app and using the <tt>rspec-rails</tt> gem, these
<tt>:request</tt> example groups may look familiar to you. That's because they
are RSpec versions of Rails integration tests. So, in this case essentially what you are getting are Capybara-enhanced request specs. This means that you can
use the Capybara helpers <i>and</i> you have access to things like named route
helpers in your tests (so you are able to say, for instance, <tt>visit
edit_user_path(user)</tt>, instead of <tt>visit "/users/#{user.id}/edit"</tt>,
if you prefer that sort of thing). A good place to put these specs is
<tt>spec/requests</tt> (or synonymously <tt>spec/integration</tt>), as
<tt>rspec-rails</tt> will automatically tag them with <tt>:type =>
:request</tt>.
<tt>rspec-rails</tt> will also automatically include Capybara in <tt>:controller</tt> and <tt>:mailer</tt> example groups.
If you are not using Rails, tag all the example groups in which you want to use
Capybara with <tt>:type => :request</tt>.
RSpec's metadata feature can be used to switch to a different driver. Use
<tt>:js => true</tt> to switch to the javascript driver, or provide a