= Capybara

* http://github.com/jnicklas/capybara

== Description:

Capybara aims to simplify the process of integration testing Rack applications,
such as Rails, Sinatra or Merb. It is inspired by and aims to replace Webrat as
a DSL for interacting with a web application. It is agnostic about the driver
running your tests and currently comes bundled with rack-test, Culerity,
Celerity and Selenium support built in. env.js support is available as the
{capybara-envjs gem}[http://github.com/smparkes/capybara-envjs].

Online documentation is availbable
{at rdoc.info}[http://rdoc.info/projects/jnicklas/capybara].

== Install:

Install as a gem:

    sudo gem install capybara

On OSX you may have to install libffi, you can install it via MacPorts with:

    sudo port install libffi

== Development:

* Source hosted at {GitHub}[http://github.com/jnicklas/capybara].
* Please direct questions, discussions at the {mailing list}[http://groups.google.com/group/ruby-capybara].
* Report issues on {GitHub Issues}[http://github.com/jnicklas/capybara/issues]

Pull requests are very welcome! 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:

    gem install bundler --pre
    bundle install

== Using Capybara with Cucumber

Capybara is built to work nicely with Cucumber. The API is very similar to
Webrat, so if you know Webrat you should feel right at home. Support for
Capybara is built into cucumber-rails 0.2. In your Rails app, just run:

    script/generate cucumber --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:

    require 'capybara/cucumber'
    Capybara.app = MyRackApp

Now you can use it in your steps:

    When /I sign in/ do
      within("#session") do
        fill_in 'Login', :with => 'user@example.com'
        fill_in 'Password', :with => 'password'
      end
      click_link 'Sign in'
    end

== Default and current driver

You can set up a default driver for your features. For example if you'd prefer
to run Selenium, you could do:

    require 'capybara/rails'
    require 'capybara/cucumber'
    Capybara.default_driver = :selenium

You can change the driver temporarily:

    Capybara.current_driver = :culerity
    Capybara.use_default_driver

You can do this in Before and After blocks to temporarily switch to a different
driver. Note that switching driver creates a new session, so you may not be able
to switch in the middle of a Scenario.

== Cucumber and Tags

Capybara sets up some {tags}[http://wiki.github.com/aslakhellesoy/cucumber/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 <tt>@javascript</tt>:

    @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 <tt>@selenium</tt>, <tt>@culerity</tt> and
<tt>@rack_test</tt> tags set up for you.

== Selenium

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

If desired, you can change Selenium browser to :chrome or :ie:

   require "selenium-webdriver"
   Selenium::WebDriver.for :chrome

== Celerity

Celerity only runs on JRuby, so you'll need to install the celerity gem under
JRuby:

   jruby -S gem install celerity

Note that some specs currently fail on celerity 0.7.5, due to a bug in recent
versions of HTMLUnit. It is recommended you use celerity 0.7.4 for the time
being.

== Culerity

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

The {capybara-envjs driver}[http://github.com/smparkes/capybara-envjs]
uses the envjs gem ({GitHub}[http://github.com/smparkes/env-js],
{rubygems.org}[http://rubygems.org/gems/envjs]) to interpret
JavaScript outside the browser. The driver is installed by installing the capybara-envjs gem:

  gem install capybara-envjs

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.

== The DSL

Capybara's DSL 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.

=== Navigating

You can use the <tt>visit</tt> method to navigate to other pages:

    visit('/projects')
    visit(post_comments_path(post))

The visit method only takes a single parameter, the request method is *always*
GET.

You can get the current path of the browsing session for test assertions:

    current_path.should == post_comments_path(post)

=== Clicking links and buttons

You can interact with the webapp by following links and buttons. Capybara
automatically follows any redirects, and submits forms associated with buttons.

    click_link('id-of-link')
    click_link('Link Text')
    click_button('Save')
    click_link_or_button('Link Text')
    click_link_or_button('Button Value')

=== Interacting with forms

Forms are everywhere in webapps, there are a number of tools for interacting
with the various form elements:

    fill_in('First Name', :with => 'John')
    fill_in('Password', :with => 'Seekrit')
    fill_in('Description', :with => 'Really Long Text…')
    choose('A Radio Button')
    check('A Checkbox')
    uncheck('A Checkbox')
    attach_file('Image', '/path/to/image.jpg')
    select('Option', :from => 'Select Box')

=== Querying

Capybara has a rich set of options for querying the page for the existence of
certain elements, and working with and manipulating those elements.

    page.has_xpath?('//table/tr')
    page.has_css?('table tr.foo')
    page.has_content?('foo')

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')
    page.should have_no_content('foo')

Note that <tt>page.should have_no_xpath</tt> is preferred over
<tt>page.should_not have_xpath</tt>. Read the section on asynchronous JavaScript
for an explanation.

=== Finding

You can also find specific elements, in order to manipulate them:

    find_field('First Name').value
    find_link('Hello').visible?
    find_button('Send').click

    find(:xpath, "//table/tr").click
    find("#overlay").find("h1").click
    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
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
to specific parts of the page:

    find('#navigation').click_link('Home')
    find('#navigation').should have_button('Sign out')

=== Scoping

Capybara makes it possible to restrict certain actions, such as interacting with
forms or clicking links and buttons, to within a specific area of the page. For
this purpose you can use the generic <tt>within</tt> method. Optionally you can
specify which kind of selector (CSS or XPath to use).

    within("//li[@id='employee']") do
      fill_in 'Name', :with => 'Jimmy'
    end

    within(:css, "li#employee") do
      fill_in 'Name', :with => 'Jimmy'
    end

You can choose which kind of selector Capybara uses by default, by setting
<tt>Capybara.default_selector</tt>.

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.

    within_fieldset('Employee') do
      fill_in 'Name', :with => 'Jimmy'
    end

    within_table('Employee') do
      fill_in 'Name', :with => 'Jimmy'
    end

=== Scripting

In drivers which support it, you can easily execute JavaScript:

    page.execute_script("$('body').empty()")

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

== 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')

The former would incorrectly wait for the content to appear, 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.

== Using the DSL outside cucumber

You can mix the DSL into any context, for example you could use it in RSpec
examples. Just load the DSL and include it anywhere:

    require 'capybara'
    require 'capybara/dsl'

    Capybara.default_driver = :culerity

    module MyModule
      include Capybara

      def login!
        within("//form[@id='session']") do
          fill_in 'Login', :with => 'user@example.com'
          fill_in 'Password', :with => 'password'
        end
        click_link 'Sign in'
      end
    end

== Calling remote servers

Normally Capybara expects to be testing an in-process Rack application, but you can also use it to talk to a web server running anywhere on the internets, by setting app_host:

    Capybara.current_driver = :selenium
    Capybara.app_host = 'http://www.google.com'
    ... 
    visit('/')

Note that rack-test does not support running against a remote server. With drivers that support it, you can also visit any URL directly:

    visit('http://www.google.com')

By default Capybara will try to boot a rack application automatically. You might want to switch off Capybara's rack server if you are running against a remote application:

    Capybara.run_server = false

== Using the sessions manually

For ultimate control, you can instantiate and use a session manually.

    require 'capybara'

    session = Capybara::Session.new(:culerity, my_rack_app)
    session.within("//form[@id='session']") do
      session.fill_in 'Login', :with => 'user@example.com'
      session.fill_in 'Password', :with => 'password'
    end
    session.click_link 'Sign in'

== XPath, CSS and selectors

Capybara does not try to guess what kind of selector you are going to give it,
if you want to use XPath with your 'within' declarations for example, you'll need
to do:

    within(:xpath, '//ul/li') { ... }
    find(:xpath, '//ul/li').text
    find(:xpath, '//li[contains(.//a[@href = "#"]/text(), "foo")]').value

Alternatively you can set the default selector to XPath:

    Capybara.default_selector = :xpath
    find('//ul/li').text

Capybara allows you to add custom selectors, which can be very useful if you
find yourself using the same kinds of selectors very often:

    Capybara::Selector.add(:id) { |id| XPath.descendant[XPath.attr(:id) == id.to_s] }
    Capybara::Selector.add(:row) { |num| ".//tbody/tr[#{num}]" }

These must always return an XPath expression as a String, or an XPath expression
generated through the XPath gem. You can now use these selectors like this:

    find(:id, 'post_123')
    find(:row, 3)

You can specify an optional :for option which will automatically use the
selector if it matches the argument to find using ===:

    Capybara::Selector.add(:id, :for => Symbol) { |id| XPath.descendant[XPath.attr(:id) == id.to_s] }

Now use it like this:

    find(:post_123)

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

== 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 <tt>controller</tt>) 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}[http://github.com/jtrupiano/timecop].

== License:

(The MIT License)

Copyright (c) 2009 Jonas Nicklas

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.