capybara

Capybara

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 discussions (please do not open an issue): https://github.com/orgs/teamcapybara/discussions/categories/q-a

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
  • Selecting the Driver
  • RackTest
  • Selenium
• The DSL
  • Navigating
  • Clicking links and buttons
  • Interacting with forms
  • Querying
  • Finding
  • Scoping
  • Working with windows
  • Scripting
  • Modals
  • Debugging
• Selectors
  • Name
  • Locator
  • Filters
• Matching
  • Exactness
  • Strategy
• Transactions and database setup
• Asynchronous JavaScript (Ajax and friends)
• Using the DSL elsewhere
• Calling remote servers
• Using sessions
  • Named sessions
  • Using sessions manually
• 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 3.0.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: '[email protected]'
    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 using Rails system specs please see their documentation for selecting the driver you wish to use.

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.create(email: '[email protected]', password: 'password')
  end

  it "signs me in" do
    visit '/sessions/new'
    within("#session") do
      fill_in 'Email', with: '[email protected]'
      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: :selenium
end

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

feature "Signing in" do
  background do
    User.create(email: '[email protected]', password: 'caplin')
  end

  scenario "Signing in with correct credentials" do
    visit '/sessions/new'
    within("#session") do
      fill_in 'Email', with: '[email protected]'
      fill_in 'Password', with: 'caplin'
    end
    click_button 'Sign in'
    expect(page).to have_content 'Success'
  end

  given(:other_user) { User.create(email: '[email protected]', 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 system tests please see their documentation for information on selecting the driver you wish to use.

• 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 = :selenium # 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 |app|
  Capybara::RackTest::Driver.new(app, headers: { 'HTTP_USER_AGENT' => 'Capybara' })
end

See the section on adding and configuring drivers.

Selenium

Capybara supports Selenium 3.5+ (Webdriver). In order to use Selenium, you'll need to install the selenium-webdriver gem, and add it to your Gemfile if you're using bundler.

Capybara pre-registers a number of named drivers that use Selenium - they are:

• :selenium => Selenium driving Firefox
• :selenium_headless => Selenium driving Firefox in a headless configuration
• :selenium_chrome => Selenium driving Chrome
• :selenium_chrome_headless => Selenium driving Chrome in a headless configuration

These should work (with relevant software installation) in a local desktop configuration but you may need to customize them if using in a CI environment where additional options may need to be passed to the browsers. See the section on adding and configuring drivers.

Note: drivers which run the server in a different thread may not share the same transaction as your tests, causing data not to be shared between your test and test server, see Transactions and database setup below.

The DSL

A complete reference is available at rubydoc.info.

Note: By default Capybara will only locate visible elements. This is because a real user would not be able to interact with non-visible elements.

Note: 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 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 get the current path of the browsing session, and test it using the have_current_path matcher:

expect(page).to have_current_path(post_comments_path(post))

Note: You can also assert the current path by testing the value of current_path directly. However, using the have_current_path matcher is safer since it uses Capybara's waiting behaviour to ensure that preceding actions (such as a click_link) have completed.

Clicking links and buttons

Full reference: Capybara::Node::Actions

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_on('Link Text') # clicks on either links or buttons
click_on('Button Value')

Interacting with forms

Full reference: Capybara::Node::Actions

There are a number of tools for interacting with 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

Full reference: Capybara::Node::Matchers

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_selector?('table tr')
page.has_selector?(:xpath, './/table/tr')

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

Note: The negative forms like has_no_selector? are different from not has_selector?. Read the section on asynchronous JavaScript for an explanation.

You can use these with RSpec's magic matchers:

expect(page).to have_selector('table tr')
expect(page).to have_selector(:xpath, './/table/tr')

expect(page).to have_xpath('.//table/tr')
expect(page).to have_css('table tr.foo')
expect(page).to have_content('foo')

Finding

Full reference: Capybara::Node::Finders

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

find_field('First Name').value
find_field(id: 'my_field').value
find_link('Hello', :visible => :all).visible?
find_link(class: ['some_class', 'some_other_class'], :visible => :all).visible?

find_button('Send').click
find_button(value: '1234').click

find(:xpath, ".//table/tr").click
find("#overlay").find("h1").click
all('a').each { |a| a[:href] }

If you need to find elements by additional attributes/properties you can also pass a filter block, which will be checked inside the normal waiting behavior. If you find yourself needing to use this a lot you may be better off adding a custom selector or adding a filter to an existing selector.

find_field('First Name'){ |el| el['data-xyz'] == '123' }
find("#img_loading"){ |img| img['complete'] == true }

Note: find 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')
expect(find('#navigation')).to 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 within method. Optionally you can specify which kind of selector to use.

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

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

There are special methods for restricting the scope to a specific fieldset, identified by either an id or the text of the fieldset'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

Working with windows

Capybara provides some methods to ease finding and switching windows:

facebook_window = window_opened_by do
  click_button 'Like'
end
within_window facebook_window do
  find('#login_email').set('[email protected]')
  find('#login_password').set('qwerty')
  click_button 'Submit'
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.

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

For more complicated scripts you'll need to write them as one expression.

result = page.evaluate_script(<<~JS, 3, element)
  (function(n, el){
    var val = parseInt(el.value, 10);
    return n+val;
  })(arguments[0], arguments[1])
JS

Modals

In drivers which support it, you can accept, dismiss and respond to alerts, confirms, and prompts.

You can accept alert messages by wrapping the code that produces an alert in a block:

accept_alert 'optional text or regex' do
  click_link('Show Alert')
end

You can accept or dismiss a confirmation by wrapping it in a block, as well:

accept_confirm 'optional text' do
  click_link('Show Confirm')
end

dismiss_confirm 'optional text' do
  click_link('Show Confirm')
end

You can accept or dismiss prompts as well, and also provide text to fill in for the response:

accept_prompt('optional text', with: 'Linus Torvalds') do
  click_link('Show Prompt About Linux')
end

dismiss_prompt('optional text') do
  click_link('Show Prompt About Linux')
end

All modal methods return the message that was presented. So, you can access the prompt message by assigning the return to a variable:

message = accept_prompt(with: 'Linus Torvalds') do
  click_link('Show Prompt About Linux')
end
expect(message).to eq('Who is the chief architect of Linux?')

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

You can also retrieve the current state of the DOM as a string using page.html.

print page.html

This is mostly useful for debugging. You should avoid testing against the contents of page.html and use the more expressive finder methods instead.

Finally, in drivers that support it, you can save a screenshot:

page.save_screenshot('screenshot.png')

Or have it save and automatically open:

save_and_open_screenshot

Screenshots are saved to Capybara.save_path, relative to the app directory. If you have required capybara/rails, Capybara.save_path will default to tmp/capybara.

Selectors

Helpers and matchers that accept Selectors share a common method signature that includes:

1. a positional Name argument
2. a positional Locator argument
3. keyword Filter arguments
4. a predicate Filter block argument

These arguments are usually optional in one way or another.

Name

The name argument determines the Selector to use. The argument is optional when a helper explicitly conveys the selector name (for example, find_field uses :field, find_link uses :link, etc):

page.html # => '<a href="/">Home</a>'

page.find(:link) == page.find_link

page.html # => '<input>'

page.find(:field) == page.find_field

Locator

The locator argument usually represents information that can most meaningfully distinguish an element that matches the selector from an element that does not:

page.html # => '<div id="greeting">Hello world</div>'

page.find(:css, 'div').text     # => 'Hello world'
page.find(:xpath, './/div').text # => 'Hello world'

General purpose finder methods like find and all can accept the locator as their first positional argument when the method can infer the default value from the Capybara.default_selector configuration: