Capybara
Note You are viewing the README for the development version of Capybara. If you are using the current release version
you can find the README at https://github.com/teamcapybara/capybara/blob/3.31_stable/README.md
Capybara helps you test web applications by simulating how a real user would
interact with your app. It is agnostic about the driver running your tests and
comes with Rack::Test and Selenium support built in. WebKit is supported
through an external gem.
Support Capybara
If you and/or your company find value in Capybara and would like to contribute financially to its ongoing maintenance and development, please visit
Patreon
Need help? Ask on the mailing list (please do not open an issue on
GitHub): http://groups.google.com/group/ruby-capybara
Table of contents
- Key benefits
- Setup
- Using Capybara with Cucumber
- Using Capybara with RSpec
- Using Capybara with Test::Unit
- Using Capybara with Minitest
- Using Capybara with Minitest::Spec
- Drivers
- The DSL
- Matching
- Transactions and database setup
- Asynchronous JavaScript (Ajax and friends)
- Using the DSL elsewhere
- Calling remote servers
- Using sessions
- XPath, CSS and selectors
- Beware the XPath // trap
- Configuring and adding drivers
- Gotchas:
- "Threadsafe" mode
- Development
Key benefits
- No setup necessary for Rails and Rack application. Works out of the box.
- Intuitive API which mimics the language an actual user would use.
- Switch the backend your tests run against from fast headless mode
to an actual browser with no changes to your tests. - Powerful synchronization features mean you never have to manually wait
for asynchronous processes to complete.
Setup
Capybara requires Ruby 2.4.0 or later. To install, add this line to your
Gemfile
and run bundle install
:
gem 'capybara'
If the application that you are testing is a Rails app, add this line to your test helper file:
require 'capybara/rails'
If the application that you are testing is a Rack app, but not Rails, set Capybara.app to your Rack app:
Capybara.app = MyRackApp
If you need to test JavaScript, or if your app interacts with (or is located at)
a remote URL, you'll need to use a different driver. If using Rails 5.0+, but not using the Rails system tests from 5.1, you'll probably also
want to swap the "server" used to launch your app to Puma in order to match Rails defaults.
Capybara.server = :puma # Until your setup is working
Capybara.server = :puma, { Silent: true } # To clean up your test output
Using Capybara with Cucumber
The cucumber-rails
gem comes with Capybara support built-in. If you
are not using Rails, manually load the capybara/cucumber
module:
require 'capybara/cucumber'
Capybara.app = MyRackApp
You can use the Capybara DSL in your steps, like so:
When /I sign in/ do
within("#session") do
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'password'
end
click_button 'Sign in'
end
You can switch to the Capybara.javascript_driver
(:selenium
by default) by tagging scenarios (or features) with @javascript
:
@javascript
Scenario: do something Ajaxy
When I click the Ajax link
...
There are also explicit tags for each registered driver set up for you (@selenium
, @rack_test
, etc).
Using Capybara with RSpec
Load RSpec 3.5+ support by adding the following line (typically to your
spec_helper.rb
file):
require 'capybara/rspec'
If you are using Rails, put your Capybara specs in spec/features
or spec/system
(only works
if you have it configured in
RSpec)
and if you have your Capybara specs in a different directory, then tag the
example groups with type: :feature
or type: :system
depending on which type of test you're writing.
If you are not using Rails, tag all the example groups in which you want to use
Capybara with type: :feature
.
You can now write your specs like so:
describe "the signin process", type: :feature do
before :each do
User.make(email: 'user@example.com', password: 'password')
end
it "signs me in" do
visit '/sessions/new'
within("#session") do
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'password'
end
click_button 'Sign in'
expect(page).to have_content 'Success'
end
end
Use js: true
to switch to the Capybara.javascript_driver
(:selenium
by default), 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: :apparition
end
Capybara also comes with a built in DSL for creating descriptive acceptance tests:
feature "Signing in" do
background do
User.make(email: 'user@example.com', password: 'caplin')
end
scenario "Signing in with correct credentials" do
visit '/sessions/new'
within("#session") do
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'caplin'
end
click_button 'Sign in'
expect(page).to have_content 'Success'
end
given(:other_user) { User.make(email: 'other@example.com', password: 'rous') }
scenario "Signing in as another user" do
visit '/sessions/new'
within("#session") do
fill_in 'Email', with: other_user.email
fill_in 'Password', with: other_user.password
end
click_button 'Sign in'
expect(page).to have_content 'Invalid email or password'
end
end
feature
is in fact just an alias for describe ..., type: :feature
,
background
is an alias for before
, scenario
for it
, and
given
/given!
aliases for let
/let!
, respectively.
Finally, Capybara matchers are also supported in view specs:
RSpec.describe "todos/show.html.erb", type: :view do
it "displays the todo title" do
assign :todo, Todo.new(title: "Buy milk")
render
expect(rendered).to have_css("header h1", text: "Buy milk")
end
end
Note: When you require 'capybara/rspec' proxy methods are installed to work around name collisions between Capybara::DSL methods
all
/within
and the identically named built-in RSpec matchers. If you opt not to require 'capybara/rspec' you can install the proxy methods by requiring 'capybara/rspec/matcher_proxies' after requiring RSpec and 'capybara/dsl'
Using Capybara with Test::Unit
-
If you are using
Test::Unit
, define a base class for your Capybara tests
like so:require 'capybara/dsl' class CapybaraTestCase < Test::Unit::TestCase include Capybara::DSL def teardown Capybara.reset_sessions! Capybara.use_default_driver end end
Using Capybara with Minitest
-
If you are using Rails, but not using Rails system tests, add the following code in your
test_helper.rb
file to make Capybara available in all test cases deriving from
ActionDispatch::IntegrationTest
:require 'capybara/rails' require 'capybara/minitest' class ActionDispatch::IntegrationTest # Make the Capybara DSL available in all integration tests include Capybara::DSL # Make `assert_*` methods behave like Minitest assertions include Capybara::Minitest::Assertions # Reset sessions and driver between tests teardown do Capybara.reset_sessions! Capybara.use_default_driver end end
-
If you are not using Rails, define a base class for your Capybara tests like
so:require 'capybara/minitest' class CapybaraTestCase < Minitest::Test include Capybara::DSL include Capybara::Minitest::Assertions def teardown Capybara.reset_sessions! Capybara.use_default_driver end end
Remember to call
super
in any subclasses that override
teardown
.
To switch the driver, set Capybara.current_driver
. For instance,
class BlogTest < ActionDispatch::IntegrationTest
setup do
Capybara.current_driver = Capybara.javascript_driver # :selenium by default
end
test 'shows blog posts' do
# ... this test is run with Selenium ...
end
end
Using Capybara with Minitest::Spec
Follow the above instructions for Minitest and additionally require capybara/minitest/spec
page.must_have_content('Important!')
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 limited: it
does not support JavaScript, nor is it able to access HTTP resources outside of
your Rack application, such as remote APIs and OAuth services. To get around
these limitations, 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 # :selenium_chrome and :selenium_chrome_headless are also registered
However, if you are using RSpec or Cucumber (and your app runs correctly without JS),
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):
Capybara.current_driver = :apparition # temporarily select different driver
# tests here
Capybara.use_default_driver # switch back to default driver
Note: 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 interacts
directly with Rack interfaces, it does not require a server to be started.
However, 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. Furthermore, you cannot use the RackTest driver to test a
remote application, or to access remote URLs (e.g., redirects to external
sites, external APIs, or OAuth services) that your application might interact
with.
capybara-mechanize
provides a similar driver that can access remote servers.
RackTest can be configured with a set of headers like this:
Capybara.register_driver :rack_test do