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 webapplication. It is agnostic about the driver running your tests and currently comes bundled with rack-test, Culerity, Celerity and Selenium support built in.
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
-
Source hosted at GitHub.
-
Please direct questions, discussions at the mailing list.
-
Report issues on GitHub Issues
-
Pull requests are very welcome!
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 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("//form[@id='session']") do fill_in 'Login', :with => '[email protected]' fill_in 'Password', :with => 'password' end click_link 'Sign in' end
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.
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.
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.
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.
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.
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.
You can use the visit 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 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 Text') # Click either a link or a button click('Button Value')
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('An Option') check('A Checkbox') uncheck('A Checkbox') attach_file('Image', '/path/to/image.jpg') select('Option', :from => 'Select Box')
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 within 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 Capybara.default_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 idea 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
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 use with RSpecs 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 page.should have_no_xpath is preferred over page.should_not have_xpath. Read the section on asynchronous JavaScript for an explanation.
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('//table/tr').click wait_for("//*[@id='overlay'").find("//h1").click all('a').each { |a| a[:href] }
In drivers which support it, you can easily evaluate JavaScript:
result = page.evaluate_script('4 + 4');
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
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 identical, 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 wait for the element to disappear from the page.
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' include Capybara Capybara.default_driver = :culerity within("//form[@id='session']") do fill_in 'Login', :with => '[email protected]' fill_in 'Password', :with => 'password' end click_link 'Sign in'
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:
require 'capybara' require 'capybara/dsl' include Capybara 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
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 => '[email protected]' session.fill_in 'Password', :with => 'password' end session.click_link 'Sign in'
Capybara does not try to guess what kind of selector you are going to give it, if you want to use CSS with your ‘within’ declarations for example, you’ll need to do:
within(:css, 'ul li') { ... }
find(:css, 'ul li').text
locate(:css, 'input#name').value
Alternatively you can set the default selector to CSS, which may help if you are moving from Webrat and used CSS a lot, or simply generally prefer CSS:
Capybara.default_selector = :css
within('ul li') { ... }
find('ul li').text
locate('input#name').value
-
Domain names (including subdomains) don’t work under rack-test. Since it’s a pain to set up subdomains for the other drivers anyway, you should consider an alternate solution. You might use default_url_options in Rails for example.
-
Access to session, request and response from the test is not possible. Maybe we’ll do response headers at some point in the future, but the others really shouldn’t be touched in an integration test anyway.
-
Access to Rails specific stuff (such as
controller) is unavailable, since we’re not using Rails’ integration testing. -
<a href="#">Will cause problems under rack-test, please do<a href="/same/url#">instead. You can achieve this in Rails withlink_to('foo', :anchor => '')
The following people have dedicated their time and effort to Capybara:
-
Jonas Nicklas
-
Dennis Rogenius
-
Rob Holland
-
Wincent Colaiuta
-
Andrea Fazzi
-
Aslak Hellesøy
-
Andrew Brown
-
Lenny Marks
-
Aaron Patterson
-
Dan Dofter
-
Thorbjørn Hermansen
-
Louis T.
-
Stephan Hagemann
-
Graham Ashton
-
Joseph Wilk
-
Matt Wynne
(The MIT License)
Copyright © 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.