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

README and History housekeeping

This commit is contained in:
Jo Liss 2011-03-14 15:27:46 +01:00
parent 6f2e8c547b
commit a0e5811ad1
2 changed files with 45 additions and 45 deletions

View file

@ -10,6 +10,7 @@ Release date:
### Changed ### Changed
* Capybara now prefers visible elements over hidden elements, disable by setting Capybara.prefer_visible_elements = false [Jonas Nicklas and Nicklas Ramhöj] * Capybara now prefers visible elements over hidden elements, disable by setting Capybara.prefer_visible_elements = false [Jonas Nicklas and Nicklas Ramhöj]
* For RSpec, :type => :request is now supported (and preferred over :acceptance) [Jo Liss]
## Fixed ## Fixed

View file

@ -7,9 +7,8 @@
Capybara aims to simplify the process of integration testing Rack applications, Capybara aims to simplify the process of integration testing Rack applications,
such as Rails, Sinatra or Merb. Capybara simulates how a real user would such as Rails, Sinatra or Merb. Capybara simulates how a real user would
interact with a web application. It is agnostic about the driver running your interact with a web application. It is agnostic about the driver running your
tests and currently comes bundled with rack-test, Culerity, Celerity and Selenium tests and currently comes with Rack::Test and Selenium support built in.
support built in. env.js support is available as the HtmlUnit and env.js are supported through external gems.
{capybara-envjs gem}[http://github.com/smparkes/capybara-envjs].
A complete reference is available at A complete reference is available at
{at rubydoc.info}[http://rubydoc.info/github/jnicklas/capybara/master]. {at rubydoc.info}[http://rubydoc.info/github/jnicklas/capybara/master].
@ -71,8 +70,8 @@ driver that supports JavaScript, Capybara makes this easy: simply tag the
scenario (or feature) with <tt>@javascript</tt>: scenario (or feature) with <tt>@javascript</tt>:
@javascript @javascript
Scenario: do something AJAXy Scenario: do something Ajaxy
When I click the AJAX link When I click the Ajax link
... ...
You can change which driver Capybara uses for JavaScript: You can change which driver Capybara uses for JavaScript:
@ -104,7 +103,7 @@ 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).
Note that 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 automatically set on all files under <tt>spec/requests</tt> (and, is automatically set on all files under <tt>spec/requests</tt> (and,
synonymously, <tt>spec/integration</tt> and <tt>spec/acceptance</tt>), so synonymously, <tt>spec/integration</tt> and <tt>spec/acceptance</tt>), so
that's a good directory to place your Capybara specs in. <tt>rspec-rails</tt> that's a good directory to place your Capybara specs in. <tt>rspec-rails</tt>
@ -159,7 +158,7 @@ Capybara uses the same DSL to drive a variety of browser and headless drivers.
=== Selecting the Driver === Selecting the Driver
By default, Capybara uses the +:rack_test+ driver, which is fast but does not By default, Capybara uses the <tt>:rack_test</tt> driver, which is fast but does not
support JavaScript. You can set up a different default driver for your support JavaScript. You can set up a different default driver for your
features. For example if you'd prefer to run everything in Selenium, you could features. For example if you'd prefer to run everything in Selenium, you could
do: do:
@ -167,11 +166,11 @@ do:
Capybara.default_driver = :selenium Capybara.default_driver = :selenium
However, if you are using RSpec or Cucumber, you may instead want to consider However, if you are using RSpec or Cucumber, you may instead want to consider
leaving the faster +:rack_test+ as the +default_driver+, and marking only those leaving the faster <tt>:rack_test</tt> as the +default_driver+, and marking only those
tests that require a JavaScript-capable driver using <tt>:js => true</tt> or tests that require a JavaScript-capable driver using <tt>:js => true</tt> or
<tt>@javascript</tt>, respectively. By default, JavaScript tests are run using the <tt>@javascript</tt>, respectively. By default, JavaScript tests are run using the
+:selenium+ driver. You can change this by setting <tt>:selenium</tt> driver. You can change this by setting
+Capybara.javascript_driver+. <tt>Capybara.javascript_driver</tt>.
You can also change the driver temporarily (typically in the Before and After You can also change the driver temporarily (typically in the Before and After
blocks): blocks):
@ -189,27 +188,26 @@ At the moment, Capybara supports {Selenium 2.0
*not* Selenium RC. Provided Firefox is installed, everything is set up for you, *not* Selenium RC. Provided Firefox is installed, everything is set up for you,
and you should be able to start using Selenium right away. and you should be able to start using Selenium right away.
By default Capybara tried to synchronize AJAX requests, so it will wait for By default Capybara tries to synchronize Ajax requests, so it will wait for
AJAX requests to finish after you've interacted with the page. You can switch Ajax requests to finish after you've interacted with the page. You can switch
off this behaviour by setting the driver option <tt>:resynchronize</tt> to off this behaviour by setting the driver option <tt>:resynchronize</tt> to
<tt>false</tt>. See the section on configuring drivers. <tt>false</tt>. See the section on configuring drivers.
=== HtmlUnit through Akephalos === HtmlUnit
{Akephalos}[https://github.com/bernerdschaefer/akephalos] is perhaps the best There are three different drivers, maintained as external gems, that you can
HtmlUnit driver right now, but you need to install the akephalos gem to use it. use to drive {HtmlUnit}[http://htmlunit.sourceforge.net/]:
=== HtmlUnit through Celerity * {Akephalos}[https://github.com/bernerdschaefer/akephalos] might be the best
HtmlUnit driver right now.
Celerity only runs on JRuby, so you'll need to install the celerity gem under * {Celerity}[https://github.com/sobrinho/capybara-celerity] only runs on JRuby,
JRuby: so you'll need to install the celerity gem under JRuby: <tt>jruby -S gem
install celerity</tt>
jruby -S gem install celerity * {Culerity}[https://github.com/sobrinho/capybara-culerity]: Install celerity
as noted above, and make sure that JRuby is in your path. Note that Culerity
=== HtmlUnit through Culerity does not seem to be working under Ruby 1.9 at the moment.
Install celerity as noted above, make sure JRuby is in your path. Note that
Culerity doesn't seem to be working under Ruby 1.9 at the moment.
=== env.js === env.js
@ -231,11 +229,6 @@ important differences. Unlike in Webrat, all searches in Capybara are *case
sensitive*. This is because Capybara heavily uses XPath, which doesn't support sensitive*. This is because Capybara heavily uses XPath, which doesn't support
case insensitivity. case insensitivity.
For a full reference of the DSL, check
{Capybara::Session}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session]
and the modules defined in
{Capybara::Node}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node].
=== Navigating === Navigating
You can use the You can use the
@ -256,6 +249,8 @@ of the browsing session for test assertions:
=== Clicking links and buttons === Clicking links and buttons
<em>Full reference: {Capybara::Node::Actions}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions]</em>
You can interact with the webapp by following links and buttons. Capybara You can interact with the webapp by following links and buttons. Capybara
automatically follows any redirects, and submits forms associated with buttons. automatically follows any redirects, and submits forms associated with buttons.
@ -267,13 +262,13 @@ automatically follows any redirects, and submits forms associated with buttons.
=== Interacting with forms === Interacting with forms
Forms are everywhere in webapps, there are a number of tools for interacting <em>Full reference: {Capybara::Node::Actions}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions]</em>
with the various form elements (see
{Capybara::Node::Actions}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions]): There are a number of tools for interacting with form elements:
fill_in('First Name', :with => 'John') fill_in('First Name', :with => 'John')
fill_in('Password', :with => 'Seekrit') fill_in('Password', :with => 'Seekrit')
fill_in('Description', :with => 'Really Long Text') fill_in('Description', :with => 'Really Long Text...')
choose('A Radio Button') choose('A Radio Button')
check('A Checkbox') check('A Checkbox')
uncheck('A Checkbox') uncheck('A Checkbox')
@ -282,9 +277,10 @@ with the various form elements (see
=== Querying === Querying
<em>Full reference: {Capybara::Node::Matchers}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Matchers]</em>
Capybara has a rich set of options for querying the page for the existence of Capybara has a rich set of options for querying the page for the existence of
certain elements, and working with and manipulating those elements (see certain elements, and working with and manipulating those elements.
{Capybara::Node::Matchers}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Matchers]).
page.has_selector?('table tr') page.has_selector?('table tr')
page.has_selector?(:xpath, '//table/tr') page.has_selector?(:xpath, '//table/tr')
@ -317,8 +313,9 @@ method to test against the raw HTML:
=== Finding === Finding
You can also find specific elements, in order to manipulate them (see <em>Full reference: {Capybara::Node::Finders}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Finders]</em>
{Capybara::Node::Finders}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Finders]):
You can also find specific elements, in order to manipulate them:
find_field('First Name').value find_field('First Name').value
find_link('Hello').visible? find_link('Hello').visible?
@ -329,7 +326,7 @@ You can also find specific elements, in order to manipulate them (see
all('a').each { |a| a[:href] } all('a').each { |a| a[:href] }
Note that <tt>find</tt> will wait for an element to appear on the page, as explained in the Note that <tt>find</tt> will wait for an element to appear on the page, as explained in the
AJAX section. If the element does not appear it will raise an error. Ajax section. If the element does not appear it will raise an error.
These elements all have all the Capybara DSL methods available, so you can restrict them These elements all have all the Capybara DSL methods available, so you can restrict them
to specific parts of the page: to specific parts of the page:
@ -383,7 +380,7 @@ look at it:
save_and_open_page save_and_open_page
== Asynchronous JavaScript (AJAX and friends) == Asynchronous JavaScript (Ajax and friends)
When working with asynchronous JavaScript, you might come across situations When working with asynchronous JavaScript, you might come across situations
where you are attempting to interact with an element which is not yet present where you are attempting to interact with an element which is not yet present
@ -397,7 +394,7 @@ When issuing instructions to the DSL such as:
page.should have_content('baz') page.should have_content('baz')
If clicking on the *foo* link causes triggers an asynchronous process, such as If clicking on the *foo* link causes triggers an asynchronous process, such as
an AJAX request, which, when complete will add the *bar* link to the page, an Ajax request, which, when complete will add the *bar* link to the page,
clicking on the *bar* link would be expeced to fail, since that link doesn't clicking on the *bar* link would be expeced to fail, since that link doesn't
exist yet. However Capybara is smart enought to retry finding the link for a exist yet. However Capybara is smart enought to retry finding the link for a
brief period of time before giving up and throwing an error. The same is true of brief period of time before giving up and throwing an error. The same is true of
@ -450,9 +447,9 @@ setting app_host:
... ...
visit('/') visit('/')
Note that the default driver (+:rack_test+) does not support running against a Note that the default driver (<tt>:rack_test</tt>) does not support running
remote server. With drivers that support it, you can also visit any URL against a remote server. With drivers that support it, you can also visit any
directly: URL directly:
visit('http://www.google.com') visit('http://www.google.com')
@ -464,7 +461,9 @@ remote application:
== Using the sessions manually == Using the sessions manually
For ultimate control, you can instantiate and use a session manually. For ultimate control, you can instantiate and use a
{Session}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session]
manually.
require 'capybara' require 'capybara'
@ -582,7 +581,7 @@ additional info about how the underlying driver can be configured.
* Freezing time: It's common practice to mock out the Time so that features * Freezing time: It's common practice to mock out the Time so that features
that depend on the current Date work as expected. This can be problematic, that depend on the current Date work as expected. This can be problematic,
since Capybara's AJAX timing uses the system time, resulting in Capybara since Capybara's Ajax timing uses the system time, resulting in Capybara
never timing out and just hanging when a failure occurs. It's still possible to never timing out and just hanging when a failure occurs. It's still possible to
use plugins which allow you to travel in time, rather than freeze time. use plugins which allow you to travel in time, rather than freeze time.
One such plugin is {Timecop}[http://github.com/jtrupiano/timecop]. One such plugin is {Timecop}[http://github.com/jtrupiano/timecop].