kotovalexarian-likes-github
/
teamcapybara--capybara
mirror of https://github.com/teamcapybara/capybara.git
1
0
Fork 0
Code Releases Activity

Modify README to clarify difference between spec/acceptance and spec/requests

This commit is contained in:
Elliot Winkler 2011-04-18 13:34:06 -06:00
parent 0ad2f9f066
commit 0befc0ee41
1 changed files with 19 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
README.rdoc
View File

@ -91,6 +91,10 @@ by adding the following line (typically to your <tt>spec_helper.rb</tt> file):
You can now use it in your examples: You can now use it in your examples:
describe "the signup process", :type => :request do describe "the signup process", :type => :request do
before :each do
User.make(:email => 'user@example.com', :password => 'caplin')
end
it "signs me in" do it "signs me in" do
within("#session") do within("#session") do
fill_in 'Login', :with => 'user@example.com' fill_in 'Login', :with => 'user@example.com'
@ -103,12 +107,13 @@ You can now use it in your examples:
Capybara is only included for examples with <tt>:type => :request</tt> (or Capybara is only included for examples with <tt>:type => :request</tt> (or
<tt>:acceptance</tt> for compatibility). <tt>:acceptance</tt> for compatibility).
If you use the <tt>rspec-rails</tt> gem, <tt>:type => :request</tt> If you use the <tt>rspec-rails</tt> gem, <tt>:type => :request</tt> is
is automatically set on all files under <tt>spec/requests</tt> (and, automatically set on all files under <tt>spec/requests</tt>. Essentially, these
synonymously, <tt>spec/integration</tt> and <tt>spec/acceptance</tt>), so are Capybara-enhanced Rails request specs, so it's a good idea to place your
that's a good directory to place your Capybara specs in. <tt>rspec-rails</tt> Capybara specs here because within request specs you gain a few additional
will also automatically include Capybara in <tt>:controller</tt> and features, such as the ability to refer to named route helpers. If you do not
<tt>:mailer</tt> examples. need these, then you may simply use <tt>spec/acceptance</tt> and you will still
get access to Capybara methods.
RSpec's metadata feature can be used to switch to a different driver. Use 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 <tt>:js => true</tt> to switch to the javascript driver, or provide a
@ -121,12 +126,12 @@ RSpec's metadata feature can be used to switch to a different driver. Use
Capybara also comes with a built in DSL for creating descriptive acceptance tests: Capybara also comes with a built in DSL for creating descriptive acceptance tests:
feature "signing up" do feature "Signing up" do
background do background do
User.make(:email => 'user@example.com', :password => 'caplin') User.make(:email => 'user@example.com', :password => 'caplin')
end end
scenario "signing in with correct credentials" do scenario "Signing in with correct credentials" do
within("#session") do within("#session") do
fill_in 'Login', :with => 'user@example.com' fill_in 'Login', :with => 'user@example.com'
fill_in 'Password', :with => 'caplin' fill_in 'Password', :with => 'caplin'
@ -135,6 +140,12 @@ Capybara also comes with a built in DSL for creating descriptive acceptance test
end end
end end
Essentially, this is just a shortcut for making a request spec, where
<tt>feature</tt> is a shortcut for <tt>describe ..., :type => :request</tt>,
<tt>background</tt> is an alias for <tt>before :each</tt>, and <tt>scenario</tt>
is an alias for <tt>it</tt>/<tt>example</tt>. Again, you are encouraged to place
these within <tt>spec/requests</tt> rather than <tt>spec/acceptance</tt>.
Note that Capybara's built in RSpec support only works with RSpec 2.0 or later. Note that Capybara's built in RSpec support only works with RSpec 2.0 or later.
You'll need to roll your own for earlier versions of RSpec. You'll need to roll your own for earlier versions of RSpec.