README.rdoc

Capybara

Description:

Capybara aims to simplify the process of integration testing Rack
applications, 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 tests and currently comes with Rack::Test and Selenium support
built in. HtmlUnit and env.js are supported through external gems.

Development:

If you found a reproducible bug, open a GitHub Issue to
submit a bug report.

Pull requests are very welcome (and even better than bug reports)! Make
sure your patches are well tested, Capybara is a testing tool after all.
Please create a topic branch for every separate change you make.

Capybara uses bundler in development. To set up a development environment,
simply do:

git submodule update --init
gem install bundler --pre
bundle install

Using Capybara with Cucumber

Capybara is built to work nicely with Cucumber. Support for Capybara is
built into cucumber-rails. In your Rails app, just run:

rails generate cucumber:install --capybara

And everything should be set up and ready to go.

If you want to use Capybara with Cucumber outside Rails (for example with
Merb or Sinatra), you'll need to require Capybara and set the Rack app
manually:

Capybara sets up some tags for you
to use in Cucumber. Often you'll want to run only some scenarios with a
driver that supports JavaScript, Capybara makes this easy: simply tag the
scenario (or feature) with @javascript:

@javascript
Scenario: do something Ajaxy
When I click the Ajax link
...

You can change which driver Capybara uses for JavaScript:

Capybara.javascript_driver = :culerity

There are also explicit @selenium, @culerity and
@rack_test tags set up for you.

Using Capybara with RSpec

If you prefer RSpec to using Cucumber, you can use the built in RSpec
support by adding the following line (typically to your
spec_helper.rb file):

Capybara is only included in example groups tagged with :type =>
:request (or :acceptance for compatibility with Steak).

If you are testing a Rails app and using the rspec-rails gem,
these :request 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 and you have
access to things like named route helpers in your tests (so you are able to
say, for instance, visit edit_user_path(user), instead of
visit "/users/#{user.id}/edit", if you prefer that sort
of thing). A good place to put these specs is spec/requests, as
rspec-rails will automatically tag them with :type =>
:request. (In fact, spec/integration and
spec/acceptance will work just as well.)

rspec-rails will also automatically include Capybara in
:controller and :mailer example groups.

RSpec's metadata feature can be used to switch to a different driver.
Use :js => true to switch to the javascript driver, or provide
a :driver option to switch to one specific driver. For example:

describe 'some stuff which requires js', :js => true do
it 'will use the default js driver'
it 'will switch to one specific driver', :driver => :celerity
end

Finally, Capybara also comes with a built in DSL for creating descriptive
acceptance tests:

This is, in fact, just a shortcut for making a request spec, where
feature is an alias for describe ..., :type =>
:request, background is an alias for before, and
scenario is an alias for it/specify.

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.

Using Capybara with Test::Unit

To use Capybara with Test::Unit, include the DSL (include Capybara
up until version 0.4.x, include Capybara::DSL for newer versions)
in whatever test class you are using. For example, if your classes derive
from ActionDispatch::IntegrationTest, use

class ActionDispatch::IntegrationTest
include Capybara::DSL
end

Test::Unit does not support selecting the driver through test metadata, but
you can switch the driver for specific classes using the setup and
teardown methods. See the section “Selecting the Driver”.

Using Capybara with Ruby on Rails

If you are using the Rails framework, add this line to automatically
configure Capybara to test against your Rails application:

require 'capybara/rails'

Using Capybara with Rack

If you're using Capybara with a non-Rails Rack application, set
Capybara.app to your application class:

Capybara.app = MyRackApp

Drivers

Capybara uses the same DSL to drive a variety of browser and headless
drivers.

Selecting the Driver

By default, Capybara uses the :rack_test driver, which is fast but
does not 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 do:

Capybara.default_driver = :selenium

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 tests that require a
JavaScript-capable driver using :js => true or
@javascript, respectively. By default, JavaScript tests are run
using the :selenium driver. You can change this by setting
Capybara.javascript_driver.

You can also change the driver temporarily (typically in the Before/setup
and After/teardown blocks):

Note that switching the driver creates a new session, so you may not be
able to switch in the middle of a test.

RackTest

RackTest is Capybara's default driver. It is written in pure Ruby and
does not have any support for executing JavaScript. Since the RackTest
driver works directly agains the Rack interface, it does not need any
server to be started, it can work directly work against any Rack app. This
means that if your application is not a Rack application (Rails, Sinatra
and most other Ruby frameworks are Rack applications) then you cannot use
this driver. You cannot use the RackTest driver to test a remote
application. capybara-mechanize
intends to provide a similar driver which works against remote servers, it
is a separate project.

Selenium

At the moment, Capybara supports Selenium
2.0 (Webdriver), not Selenium RC. Provided Firefox is installed,
everything is set up for you, and you should be able to start using
Selenium right away.

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 off this behaviour by setting the driver option
:resynchronize to false. See the section on configuring
drivers.

Note: Selenium does not support transactional fixtures; see the section
“Transactional Fixtures” below.

HtmlUnit

There are three different drivers, maintained as external gems, that you
can use to drive HtmlUnit:

env.js

More info about the driver and env.js are available through the links
above. The envjs gem only supports Ruby 1.8.7 at this time.

Note: Envjs does not support transactional fixtures; see the section
“Transactional Fixtures” below.

The DSL

Capybara's DSL (domain-specific language) is inspired by Webrat. While
backwards compatibility is retained in a lot of cases, there are certain
important differences. Unlike in Webrat, all searches in Capybara are
*case sensitive*. This is because Capybara heavily uses XPath, which
doesn't support case insensitivity.

Note that within will scope the actions to the first (not
any) element that matches the selector.

There are special methods for restricting the scope to a specific fieldset,
identified by either an id or the text of the fieldet's legend tag, and
to a specific table, identified by either id or text of the table's
caption tag.

Scripting

For simple expressions, you can return the result of the script. Note that
this may break with more complicated expressions:

result = page.evaluate_script('4 + 4');

Debugging

It can be useful to take a snapshot of the page as it currently is and take
a look at it:

save_and_open_page

Transactional fixtures

Transactional fixtures only work in the default Rack::Test driver, but not
for other drivers like Selenium. Cucumber takes care of this
automatically, but with Test::Unit or RSpec, you may have to use the database_cleaner gem.
See this
explanation (and code for solution
2 and solution 3) for details.

Asynchronous JavaScript (Ajax and friends)

When working with asynchronous JavaScript, you might come across situations
where you are attempting to interact with an element which is not yet
present on the page. Capybara automatically deals with this by waiting for
elements to appear on the page.

When issuing instructions to the DSL such as:

click_link('foo')
click_link('bar')
page.should have_content('baz')

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, 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 brief period of time before giving up and
throwing an error. The same is true of the next line, which looks for the
content baz on the page; it will retry looking for that content for
a brief time. You can adjust how long this period is (the default is 2
seconds):

Capybara.default_wait_time = 5

Be aware that because of this behaviour, the following two statements are
not equivalent, and you should always use the latter!

page.should_not have_xpath('a')
page.should have_no_xpath('a')

Imagine we have an asynchronous process that removes the a from the page.
The former will wait for the content to appear, and exit immediately since
the asynchronous process has not yet removed the element from the page. It
would therefore fail, even though the code might be working correctly. The
latter correctly waits for the element to disappear from the page.

If you are sure you have no asynchronous processes that can affect your
particular element, you can turn off this behaviour for has_xpath?,
has_css? and has_selector? ( and their negative counterparts)

This :id selector is already built into Capybara by default, so you
don't need to add it yourself.

Beware the XPath // trap

In XPath the expression // means something very specific, and it might not
be what you think. Contrary to common belief, // means “anywhere in the
document” not “anywhere in the current context”. As an example:

page.find(:xpath, '//body').all(:xpath, '//script')

You might expect this to find all script tags in the body, but actually, it
finds all script tags in the entire document, not only those in the body!
What you're looking for is the .// expression which means “any
descendant of the current node”:

page.find(:xpath, '//body').all(:xpath, './/script')

The same thing goes for within:

within(:xpath, '//body') do
page.find(:xpath, './/script')
within(:xpath, './/table/tbody') do
...
end
end

Configuring and adding drivers

Capybara makes it convenient to switch between different drivers. It also
exposes an API to tweak those drivers with whatever settings you want, or
to add your own drivers. This is how to switch the selenium driver to use
chrome:

Whatever is returned from the block should conform to the API described by
Capybara::Driver::Base, it does not however have to inherit from this
class. Gems can use this API to add their own drivers to Capybara.

The Selenium
wiki has additional info about how the underlying driver can be
configured.

Gotchas:

Access to session and request is not possible from the test, Access to
response is limited. Some drivers allow access to response headers and HTTP
status code, but this kind of functionality is not provided by some
drivers, such as Selenium.

Access to Rails specific stuff (such as controller) is
unavailable, since we're not using Rails' integration testing.

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, 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 use plugins which allow you to travel in
time, rather than freeze time. One such plugin is Timecop.

When using Rack::Test, beware if attempting to visit absolute URLs. For
example, a session might not be shared between visits to
posts_path and posts_url. If testing an absolute URL in
an Action Mailer email, set default_url_options to match the Rails
default of www.example.com.

License:

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
'Software'), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the
following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
USE OR OTHER DEALINGS IN THE SOFTWARE.