2012-01-04 00:00:27 +00:00
# Capybara
2009-11-04 22:00:05 +00:00
2016-11-15 17:14:43 +00:00
[![Build Status ](https://secure.travis-ci.org/teamcapybara/capybara.svg )](https://travis-ci.org/teamcapybara/capybara)
2018-03-16 18:10:31 +00:00
[![Build Status ](https://ci.appveyor.com/api/projects/status/github/teamcapybara/capybara?svg=true )](https://ci.appveyor.com/api/projects/github/teamcapybara/capybara)
2016-11-22 16:26:34 +00:00
[![Code Climate ](https://codeclimate.com/github/teamcapybara/capybara.svg )](https://codeclimate.com/github/teamcapybara/capybara)
2019-04-25 22:26:14 +00:00
[![Coverage Status ](https://coveralls.io/repos/github/teamcapybara/capybara/badge.svg?branch=master )](https://coveralls.io/github/teamcapybara/capybara?branch=master)
2016-07-29 19:17:58 +00:00
[![Gitter ](https://badges.gitter.im/Join%20Chat.svg )](https://gitter.im/jnicklas/capybara?utm_source=badge& utm_medium=badge& utm_campaign=pr-badge& utm_content=badge)
2018-06-15 19:11:07 +00:00
[![SemVer ](https://api.dependabot.com/badges/compatibility_score?dependency-name=capybara&package-manager=bundler&version-scheme=semver )](https://dependabot.com/compatibility-score.html?dependency-name=capybara& package-manager=bundler& version-scheme=semver)
2012-01-04 08:09:44 +00:00
2019-05-29 23:13:32 +00:00
**Note** You are viewing the README for the development version of Capybara. If you are using the current release version
2019-07-15 20:27:38 +00:00
you can find the README at https://github.com/teamcapybara/capybara/blob/3.26_stable/README.md
2018-01-03 23:24:10 +00:00
2012-09-28 14:23:46 +00:00
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.
2009-11-04 22:00:05 +00:00
2017-09-17 20:41:41 +00:00
## 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
< a href = "https://www.patreon.com/capybara" > Patreon< / a >
2012-01-04 00:00:27 +00:00
**Need help?** Ask on the mailing list (please do not open an issue on
2011-12-25 23:05:38 +00:00
GitHub): http://groups.google.com/group/ruby-capybara
2009-11-04 22:00:05 +00:00
2015-02-25 20:46:42 +00:00
## Table of contents
- [Key benefits ](#key-benefits )
- [Setup ](#setup )
- [Using Capybara with Cucumber ](#using-capybara-with-cucumber )
- [Using Capybara with RSpec ](#using-capybara-with-rspec )
- [Using Capybara with Test::Unit ](#using-capybara-with-testunit )
2017-03-07 13:46:05 +00:00
- [Using Capybara with Minitest ](#using-capybara-with-minitest )
- [Using Capybara with Minitest::Spec ](#using-capybara-with-minitestspec )
2015-02-25 20:46:42 +00:00
- [Drivers ](#drivers )
- [Selecting the Driver ](#selecting-the-driver )
- [RackTest ](#racktest )
- [Selenium ](#selenium )
2019-01-23 23:55:51 +00:00
- [Apparition ](#apparition )
2015-11-08 09:13:08 +00:00
- [The DSL ](#the-dsl )
2015-02-25 20:46:42 +00:00
- [Navigating ](#navigating )
- [Clicking links and buttons ](#clicking-links-and-buttons )
- [Interacting with forms ](#interacting-with-forms )
- [Querying ](#querying )
- [Finding ](#finding )
- [Scoping ](#scoping )
- [Working with windows ](#working-with-windows )
- [Scripting ](#scripting )
- [Modals ](#modals )
- [Debugging ](#debugging )
- [Matching ](#matching )
- [Exactness ](#exactness )
- [Strategy ](#strategy )
- [Transactions and database setup ](#transactions-and-database-setup )
- [Asynchronous JavaScript (Ajax and friends) ](#asynchronous-javascript-ajax-and-friends )
- [Using the DSL elsewhere ](#using-the-dsl-elsewhere )
- [Calling remote servers ](#calling-remote-servers )
2016-06-11 06:52:47 +00:00
- [Using sessions ](#using-sessions )
2019-05-19 13:34:58 +00:00
- [Named sessions ](#named-sessions )
- [Using sessions manually ](#using-sessions-manually )
2015-02-25 20:46:42 +00:00
- [XPath, CSS and selectors ](#xpath-css-and-selectors )
- [Beware the XPath // trap ](#beware-the-xpath--trap )
- [Configuring and adding drivers ](#configuring-and-adding-drivers )
- [Gotchas: ](#gotchas )
2019-05-19 13:34:58 +00:00
- ["Threadsafe" mode ](#threadsafe-mode )
2015-02-25 20:46:42 +00:00
- [Development ](#development )
2016-04-05 09:57:13 +00:00
## <a name="key-benefits"></a>Key benefits
2012-09-28 14:23:46 +00:00
- **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
2012-10-03 16:05:25 +00:00
for asynchronous processes to complete.
2012-09-28 14:23:46 +00:00
2016-04-05 09:57:13 +00:00
## <a name="setup"></a>Setup
2009-11-04 22:00:05 +00:00
2019-04-03 20:02:05 +00:00
Capybara requires Ruby 2.4.0 or later. To install, add this line to your
2014-01-06 18:55:28 +00:00
`Gemfile` and run `bundle install` :
2010-07-17 17:07:50 +00:00
2014-01-06 18:55:28 +00:00
```ruby
gem 'capybara'
2012-01-04 00:00:27 +00:00
```
2009-11-24 23:18:33 +00:00
2013-03-27 22:35:05 +00:00
If the application that you are testing is a Rails app, add this line to your test helper file:
2009-11-24 23:18:33 +00:00
2012-01-04 00:00:27 +00:00
```ruby
require 'capybara/rails'
```
2009-11-24 23:18:33 +00:00
2013-03-27 22:35:05 +00:00
If the application that you are testing is a Rack app, but not Rails, set Capybara.app to your Rack app:
2010-01-17 15:31:40 +00:00
2012-01-04 00:00:27 +00:00
```ruby
Capybara.app = MyRackApp
```
2010-01-17 15:31:40 +00:00
2012-07-17 17:03:30 +00:00
If you need to test JavaScript, or if your app interacts with (or is located at)
2017-08-01 23:50:05 +00:00
a remote URL, you'll need to [use a different driver ](#drivers ). 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.
```ruby
Capybara.server = :puma # Until your setup is working
Capybara.server = :puma, { Silent: true } # To clean up your test output
```
2012-07-17 17:03:30 +00:00
2016-04-05 09:57:13 +00:00
## <a name="using-capybara-with-cucumber"></a>Using Capybara with Cucumber
2009-11-04 22:00:05 +00:00
2012-01-04 00:00:27 +00:00
The `cucumber-rails` gem comes with Capybara support built-in. If you
are not using Rails, manually load the `capybara/cucumber` module:
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
```ruby
require 'capybara/cucumber'
Capybara.app = MyRackApp
```
2009-11-18 23:00:10 +00:00
2011-12-21 17:02:33 +00:00
You can use the Capybara DSL in your steps, like so:
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
```ruby
When /I sign in/ do
within("#session") do
2016-10-04 18:10:29 +00:00
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'password'
2012-01-04 00:00:27 +00:00
end
2014-05-29 16:41:42 +00:00
click_button 'Sign in'
2012-01-04 00:00:27 +00:00
end
```
You can switch to the `Capybara.javascript_driver` (`:selenium`
by default) by tagging scenarios (or features) with `@javascript` :
```ruby
@javascript
Scenario: do something Ajaxy
When I click the Ajax link
...
```
2017-08-04 07:22:57 +00:00
There are also explicit tags for each registered driver set up for you (`@selenium`, `@rack_test` , etc).
2010-12-10 13:54:46 +00:00
2016-04-05 09:57:13 +00:00
## <a name="using-capybara-with-rspec"></a>Using Capybara with RSpec
2010-12-10 13:54:46 +00:00
2018-11-19 18:21:55 +00:00
Load RSpec 3.5+ support by adding the following line (typically to your
2012-01-04 00:00:27 +00:00
`spec_helper.rb` file):
2010-12-10 13:54:46 +00:00
2012-01-04 00:00:27 +00:00
```ruby
require 'capybara/rspec'
```
2010-12-10 13:54:46 +00:00
2018-02-15 12:04:43 +00:00
If you are using Rails, put your Capybara specs in `spec/features` or `spec/system` (only works
2015-12-26 16:02:38 +00:00
if [you have it configured in
2016-02-23 14:27:54 +00:00
RSpec](https://www.relishapp.com/rspec/rspec-rails/docs/upgrade#file-type-inference-disabled))
2015-12-26 16:02:38 +00:00
and if you have your Capybara specs in a different directory, then tag the
2018-04-04 21:28:04 +00:00
example groups with `type: :feature` or `type: :system` depending on which type of test you're writing.
2011-12-21 17:02:33 +00:00
If you are not using Rails, tag all the example groups in which you want to use
2018-04-04 21:28:04 +00:00
Capybara with `type: :feature` .
2011-12-21 17:02:33 +00:00
2011-04-28 22:08:05 +00:00
You can now write your specs like so:
2010-12-10 13:54:46 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2018-04-04 21:28:04 +00:00
describe "the signin process", type: :feature do
2012-01-04 00:00:27 +00:00
before :each do
2016-10-04 18:10:29 +00:00
User.make(email: 'user@example.com', password: 'password')
2012-01-04 00:00:27 +00:00
end
2011-04-25 09:35:57 +00:00
2012-01-04 00:00:27 +00:00
it "signs me in" do
2013-01-08 14:53:37 +00:00
visit '/sessions/new'
2012-01-04 00:00:27 +00:00
within("#session") do
2016-10-04 18:10:29 +00:00
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'password'
2010-12-10 13:54:46 +00:00
end
2014-05-29 16:41:42 +00:00
click_button 'Sign in'
2013-06-15 02:57:33 +00:00
expect(page).to have_content 'Success'
2012-01-04 00:00:27 +00:00
end
end
```
2010-12-10 13:54:46 +00:00
2016-10-04 18:10:29 +00:00
Use `js: true` to switch to the `Capybara.javascript_driver`
2012-01-04 00:00:27 +00:00
(`:selenium` by default), or provide a `:driver` option to switch
2011-12-21 17:02:33 +00:00
to one specific driver. For example:
2010-12-10 13:54:46 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2016-10-04 18:10:29 +00:00
describe 'some stuff which requires js', js: true do
2012-01-04 00:00:27 +00:00
it 'will use the default js driver'
2019-05-09 15:26:26 +00:00
it 'will switch to one specific driver', driver: :apparition
2012-01-04 00:00:27 +00:00
end
```
2010-12-10 13:54:46 +00:00
2015-06-05 18:16:13 +00:00
Capybara also comes with a built in DSL for creating descriptive acceptance tests:
2011-02-11 13:44:58 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2013-06-13 16:28:52 +00:00
feature "Signing in" do
2012-01-04 00:00:27 +00:00
background do
2016-10-04 18:10:29 +00:00
User.make(email: 'user@example.com', password: 'caplin')
2012-01-04 00:00:27 +00:00
end
2011-02-11 13:44:58 +00:00
2012-01-04 00:00:27 +00:00
scenario "Signing in with correct credentials" do
2013-01-08 14:53:37 +00:00
visit '/sessions/new'
2012-01-04 00:00:27 +00:00
within("#session") do
2016-10-04 18:10:29 +00:00
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'caplin'
2011-02-11 13:44:58 +00:00
end
2014-05-29 16:41:42 +00:00
click_button 'Sign in'
2013-06-15 02:57:33 +00:00
expect(page).to have_content 'Success'
2012-01-04 00:00:27 +00:00
end
2012-10-03 22:49:44 +00:00
2016-10-04 18:10:29 +00:00
given(:other_user) { User.make(email: 'other@example.com', password: 'rous') }
2012-11-14 15:52:59 +00:00
2012-10-03 22:49:44 +00:00
scenario "Signing in as another user" do
2013-01-08 14:53:37 +00:00
visit '/sessions/new'
2012-10-03 22:49:44 +00:00
within("#session") do
2016-10-04 18:10:29 +00:00
fill_in 'Email', with: other_user.email
fill_in 'Password', with: other_user.password
2012-10-03 22:49:44 +00:00
end
2014-05-29 16:41:42 +00:00
click_button 'Sign in'
2013-06-15 02:57:33 +00:00
expect(page).to have_content 'Invalid email or password'
2012-10-03 22:49:44 +00:00
end
2012-01-04 00:00:27 +00:00
end
```
2011-02-11 13:44:58 +00:00
2019-01-04 15:13:58 +00:00
`feature` is in fact just an alias for `describe ..., type: :feature` ,
2012-11-14 15:52:59 +00:00
`background` is an alias for `before` , `scenario` for `it` , and
`given` /`given!` aliases for `let` /`let!`, respectively.
2010-12-10 13:54:46 +00:00
2018-01-02 22:03:57 +00:00
Finally, Capybara matchers are also supported in view specs:
2015-06-05 18:16:13 +00:00
```ruby
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
```
2017-03-28 17:41:49 +00:00
**Note: When you require 'capybara/rspec' proxy methods are installed to work around name collisions between Capybara::DSL methods
2017-04-12 19:46:40 +00:00
`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'**
2017-03-28 17:41:49 +00:00
2016-04-05 09:57:13 +00:00
## <a name="using-capybara-with-testunit"></a>Using Capybara with Test::Unit
2011-04-14 13:46:22 +00:00
2017-03-07 13:46:05 +00:00
* If you are using `Test::Unit` , define a base class for your Capybara tests
like so:
```ruby
require 'capybara/dsl'
class CapybaraTestCase < Test::Unit::TestCase
include Capybara::DSL
def teardown
Capybara.reset_sessions!
Capybara.use_default_driver
end
end
```
## <a name="using-capybara-with-minitest"></a>Using Capybara with Minitest
2019-05-09 15:26:26 +00:00
* If you are using Rails, but not using Rails system tests, add the following code in your `test_helper.rb`
2013-03-07 19:46:37 +00:00
file to make Capybara available in all test cases deriving from
2012-01-04 00:00:27 +00:00
`ActionDispatch::IntegrationTest` :
```ruby
2017-03-07 13:46:05 +00:00
require 'capybara/rails'
require 'capybara/minitest'
2012-01-04 00:00:27 +00:00
class ActionDispatch::IntegrationTest
# Make the Capybara DSL available in all integration tests
include Capybara::DSL
2017-03-07 13:46:05 +00:00
# Make `assert_*` methods behave like Minitest assertions
include Capybara::Minitest::Assertions
2014-08-12 07:17:52 +00:00
# Reset sessions and driver between tests
2019-05-02 21:58:34 +00:00
teardown do
2014-08-12 07:17:52 +00:00
Capybara.reset_sessions!
Capybara.use_default_driver
end
2012-01-04 00:00:27 +00:00
end
```
2011-12-26 20:00:40 +00:00
* If you are not using Rails, define a base class for your Capybara tests like
so:
2012-01-04 00:00:27 +00:00
```ruby
2017-03-07 13:46:05 +00:00
require 'capybara/minitest'
class CapybaraTestCase < Minitest::Test
2012-01-04 00:00:27 +00:00
include Capybara::DSL
2017-03-07 13:46:05 +00:00
include Capybara::Minitest::Assertions
2011-12-26 20:00:40 +00:00
2012-01-04 00:00:27 +00:00
def teardown
Capybara.reset_sessions!
Capybara.use_default_driver
2011-12-26 20:00:40 +00:00
end
2012-01-04 00:00:27 +00:00
end
```
2011-12-26 20:00:40 +00:00
2012-01-04 00:00:27 +00:00
Remember to call `super` in any subclasses that override
`teardown` .
2011-12-26 20:00:40 +00:00
2012-01-04 00:00:27 +00:00
To switch the driver, set `Capybara.current_driver` . For instance,
2011-04-14 13:46:22 +00:00
2012-01-04 00:00:27 +00:00
```ruby
class BlogTest < ActionDispatch::IntegrationTest
setup do
Capybara.current_driver = Capybara.javascript_driver # :selenium by default
end
2011-12-26 20:00:40 +00:00
2012-06-04 10:11:53 +00:00
test 'shows blog posts' do
2012-01-04 00:00:27 +00:00
# ... this test is run with Selenium ...
end
end
```
2011-04-14 13:53:58 +00:00
2017-03-07 13:46:05 +00:00
## <a name="using-capybara-with-minitestspec"></a>Using Capybara with Minitest::Spec
2017-03-03 21:06:07 +00:00
2017-03-07 13:46:05 +00:00
Follow the above instructions for Minitest and additionally require capybara/minitest/spec
2011-09-26 13:44:33 +00:00
2012-01-04 00:00:27 +00:00
```ruby
page.must_have_content('Important!')
```
2011-09-26 13:44:33 +00:00
2016-04-05 09:57:13 +00:00
## <a name="drivers"></a>Drivers
2009-11-18 23:00:10 +00:00
2011-02-19 00:18:57 +00:00
Capybara uses the same DSL to drive a variety of browser and headless drivers.
2016-04-05 09:57:13 +00:00
### <a name="selecting-the-driver"></a>Selecting the Driver
2011-02-19 00:18:57 +00:00
2012-07-17 17:03:30 +00:00
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:
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2017-08-04 07:22:57 +00:00
Capybara.default_driver = :selenium # :selenium_chrome and :selenium_chrome_headless are also registered
2012-01-04 00:00:27 +00:00
```
2009-11-18 23:00:10 +00:00
2019-05-09 15:26:26 +00:00
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
2012-01-04 00:00:27 +00:00
`@javascript` , respectively. By default, JavaScript tests are run using the
`:selenium` driver. You can change this by setting
`Capybara.javascript_driver` .
2011-02-19 00:18:57 +00:00
2011-04-14 13:53:58 +00:00
You can also change the driver temporarily (typically in the Before/setup and
After/teardown blocks):
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2019-05-09 15:26:26 +00:00
Capybara.current_driver = :apparition # temporarily select different driver
2015-08-25 20:35:43 +00:00
# tests here
2012-01-04 00:00:27 +00:00
Capybara.use_default_driver # switch back to default driver
```
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
**Note**: switching the driver creates a new session, so you may not be able to
2011-02-19 00:18:57 +00:00
switch in the middle of a test.
2009-12-14 21:07:51 +00:00
2016-04-05 09:57:13 +00:00
### <a name="racktest"></a>RackTest
2011-04-25 09:35:57 +00:00
RackTest is Capybara's default driver. It is written in pure Ruby and does not
2012-07-17 17:03:30 +00:00
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
2012-07-17 17:19:30 +00:00
remote application, or to access remote URLs (e.g., redirects to external
sites, external APIs, or OAuth services) that your application might interact
with.
2012-07-17 17:03:30 +00:00
2012-01-04 00:00:27 +00:00
[capybara-mechanize ](https://github.com/jeroenvandijk/capybara-mechanize )
2012-07-17 17:03:30 +00:00
provides a similar driver that can access remote servers.
2011-04-25 09:35:57 +00:00
RackTest can be configured with a set of headers like this:
2012-01-04 00:00:27 +00:00
```ruby
Capybara.register_driver :rack_test do |app|
2016-10-04 18:10:29 +00:00
Capybara::RackTest::Driver.new(app, headers: { 'HTTP_USER_AGENT' => 'Capybara' })
2012-01-04 00:00:27 +00:00
end
```
2011-04-25 09:35:57 +00:00
See the section on adding and configuring drivers.
2016-04-05 09:57:13 +00:00
### <a name="selenium"></a>Selenium
2009-11-18 23:00:10 +00:00
2018-07-14 16:07:08 +00:00
Capybara supports [Selenium 3.5+
(Webdriver)](https://www.seleniumhq.org/projects/webdriver/).
2018-08-14 17:34:17 +00:00
In order to use Selenium, you'll need to install the `selenium-webdriver` gem,
2018-07-14 16:07:08 +00:00
and add it to your Gemfile if you're using bundler.
2009-11-18 23:00:10 +00:00
2018-08-14 17:34:17 +00:00
Capybara pre-registers a number of named drives that use Selenium - they are:
* :selenium => Selenium driving Firefox
2018-11-20 20:27:53 +00:00
* :selenium_headless => Selenium driving Firefox in a headless configuration
2018-08-14 17:34:17 +00:00
* :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.
2013-10-20 18:16:00 +00:00
**Note**: drivers which run the server in a different thread may not share the
2012-01-03 13:40:51 +00:00
same transaction as your tests, causing data not to be shared between your test
2018-11-20 19:22:24 +00:00
and test server, see [Transactions and database setup ](#transactions-and-database-setup ) below.
2011-04-14 13:39:34 +00:00
2019-01-23 23:51:23 +00:00
### <a name="apparition"></a>Apparition
2019-05-09 15:26:26 +00:00
The [apparition driver ](https://github.com/twalpole/apparition ) is a new driver that allows you to run tests using Chrome in a headless
2019-01-23 23:51:23 +00:00
or headed configuration. It attempts to provide backwards compatibility with the [Poltergeist driver API ](https://github.com/teampoltergeist/poltergeist )
2019-05-09 15:26:26 +00:00
and [capybara-webkit API ](https://github.com/thoughtbot/capybara-webkit ) while allowing for the use of modern JS/CSS. It
uses CDP to communicate with Chrome, thereby obviating the need for chromedriver. This driver is being developed by the
current developer of Capybara and will attempt to keep up to date with new Capybara releases. It will probably be moved into the
teamcapybara repo once it reaches v1.0.
2012-04-15 18:57:58 +00:00
2016-04-05 09:57:13 +00:00
## <a name="the-dsl"></a>The DSL
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
*A complete reference is available at
2016-11-15 17:14:43 +00:00
[rubydoc.info ](http://rubydoc.info/github/teamcapybara/capybara/master )*.
2011-12-21 17:02:33 +00:00
2015-08-04 17:26:37 +00:00
**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.**
2012-01-04 00:00:27 +00:00
**Note**: All searches in Capybara are *case sensitive* . This is because
2011-12-21 17:02:33 +00:00
Capybara heavily uses XPath, which doesn't support case insensitivity.
2009-12-12 12:37:29 +00:00
2016-04-05 09:57:13 +00:00
### <a name="navigating"></a>Navigating
2009-12-25 17:00:27 +00:00
2011-02-04 14:06:30 +00:00
You can use the
2016-11-15 17:14:43 +00:00
< tt > [visit](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#visit-instance_method)< / tt >
2011-02-04 14:06:30 +00:00
method to navigate to other pages:
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
```ruby
visit('/projects')
visit(post_comments_path(post))
```
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
The visit method only takes a single parameter, the request method is **always**
2009-12-25 17:00:27 +00:00
GET.
2016-11-15 17:14:43 +00:00
You can get the [current path ](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#current_path-instance_method )
of the browsing session, and test it using the [`have_current_path` ](http://www.rubydoc.info/github/teamcapybara/capybara/master/Capybara/RSpecMatchers#have_current_path-instance_method ) matcher:
2010-04-07 15:20:59 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2015-12-23 00:03:23 +00:00
expect(page).to have_current_path(post_comments_path(post))
2012-01-04 00:00:27 +00:00
```
2010-04-07 15:20:59 +00:00
2015-12-23 00:03:23 +00:00
**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 ](#asynchronous-javascript-ajax-and-friends )
to ensure that preceding actions (such as a `click_link` ) have completed.
2016-04-05 09:57:13 +00:00
### <a name="clicking-links-and-buttons"></a>Clicking links and buttons
2009-12-25 17:00:27 +00:00
2016-11-15 17:14:43 +00:00
*Full reference: [Capybara::Node::Actions ](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Actions )*
2011-03-14 14:27:46 +00:00
2009-12-25 17:00:27 +00:00
You can interact with the webapp by following links and buttons. Capybara
automatically follows any redirects, and submits forms associated with buttons.
2012-01-04 00:00:27 +00:00
```ruby
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')
```
2009-12-25 17:00:27 +00:00
2016-04-05 09:57:13 +00:00
### <a name="interacting-with-forms"></a>Interacting with forms
2009-12-25 17:00:27 +00:00
2016-11-15 17:14:43 +00:00
*Full reference: [Capybara::Node::Actions ](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Actions )*
2011-03-14 14:27:46 +00:00
There are a number of tools for interacting with form elements:
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2016-10-04 18:10:29 +00:00
fill_in('First Name', with: 'John')
fill_in('Password', with: 'Seekrit')
fill_in('Description', with: 'Really Long Text...')
2012-01-04 00:00:27 +00:00
choose('A Radio Button')
check('A Checkbox')
uncheck('A Checkbox')
attach_file('Image', '/path/to/image.jpg')
2016-10-04 18:10:29 +00:00
select('Option', from: 'Select Box')
2012-01-04 00:00:27 +00:00
```
2009-12-25 17:00:27 +00:00
2016-04-05 09:57:13 +00:00
### <a name="querying"></a>Querying
2009-12-25 17:00:27 +00:00
2016-11-15 17:14:43 +00:00
*Full reference: [Capybara::Node::Matchers ](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Matchers )*
2011-03-14 14:27:46 +00:00
2009-12-25 17:00:27 +00:00
Capybara has a rich set of options for querying the page for the existence of
2011-03-14 14:27:46 +00:00
certain elements, and working with and manipulating those elements.
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
```ruby
page.has_selector?('table tr')
2016-10-26 19:24:51 +00:00
page.has_selector?(:xpath, './/table/tr')
2010-10-12 11:26:24 +00:00
2016-10-26 19:24:51 +00:00
page.has_xpath?('.//table/tr')
2012-01-04 00:00:27 +00:00
page.has_css?('table tr.foo')
2012-01-10 13:30:49 +00:00
page.has_content?('foo')
2012-01-04 00:00:27 +00:00
```
2010-02-03 12:18:20 +00:00
2012-01-04 18:16:35 +00:00
**Note:** The negative forms like `has_no_selector?` are different from `not
has_selector?`. Read the section on asynchronous JavaScript for an explanation.
2011-02-01 00:43:16 +00:00
You can use these with RSpec's magic matchers:
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2013-11-14 17:43:36 +00:00
expect(page).to have_selector('table tr')
2016-10-26 19:24:51 +00:00
expect(page).to have_selector(:xpath, './/table/tr')
2010-10-12 11:26:24 +00:00
2016-10-26 19:24:51 +00:00
expect(page).to have_xpath('.//table/tr')
2013-11-14 17:43:36 +00:00
expect(page).to have_css('table tr.foo')
expect(page).to have_content('foo')
2012-01-04 00:00:27 +00:00
```
2011-10-16 23:46:19 +00:00
2016-04-05 09:57:13 +00:00
### <a name="finding"></a>Finding
2010-07-10 15:10:54 +00:00
2016-11-15 17:14:43 +00:00
_Full reference: [Capybara::Node::Finders ](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders )_
2011-03-14 14:27:46 +00:00
You can also find specific elements, in order to manipulate them:
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
```ruby
find_field('First Name').value
2016-10-10 22:10:41 +00:00
find_field(id: 'my_field').value
2015-08-04 17:26:37 +00:00
find_link('Hello', :visible => :all).visible?
2016-10-10 22:10:41 +00:00
find_link(class: ['some_class', 'some_other_class'], :visible => :all).visible?
2012-01-04 00:00:27 +00:00
find_button('Send').click
2016-10-10 22:10:41 +00:00
find_button(value: '1234').click
2010-02-03 12:18:20 +00:00
2016-10-26 19:24:51 +00:00
find(:xpath, ".//table/tr").click
2012-01-04 00:00:27 +00:00
find("#overlay").find("h1").click
all('a').each { |a| a[:href] }
```
2009-12-25 17:00:27 +00:00
2016-10-05 17:03:04 +00:00
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.
2016-11-15 17:14:43 +00:00
If you find yourself needing to use this a lot you may be better off adding a [custom selector ](http://www.rubydoc.info/github/teamcapybara/capybara/Capybara#add_selector-class_method ) or [adding a filter to an existing selector ](http://www.rubydoc.info/github/teamcapybara/capybara/Capybara#modify_selector-class_method ).
2016-10-05 17:03:04 +00:00
```ruby
find_field('First Name'){ |el| el['data-xyz'] == '123' }
2016-10-10 22:10:41 +00:00
find("#img_loading"){ |img| img['complete'] == true }
2017-11-01 13:55:50 +00:00
```
2016-10-05 17:03:04 +00:00
2012-01-04 00:00:27 +00:00
**Note**: `find` will wait for an element to appear on the page, as explained in the
2011-03-14 14:27:46 +00:00
Ajax section. If the element does not appear it will raise an error.
2010-07-10 14:56:20 +00:00
2010-07-10 15:10:54 +00:00
These elements all have all the Capybara DSL methods available, so you can restrict them
to specific parts of the page:
2012-01-04 00:00:27 +00:00
```ruby
find('#navigation').click_link('Home')
2013-11-14 17:43:36 +00:00
expect(find('#navigation')).to have_button('Sign out')
2012-01-04 00:00:27 +00:00
```
2010-07-10 15:10:54 +00:00
2016-04-05 09:57:13 +00:00
### <a name="scoping"></a>Scoping
2010-07-10 15:10:54 +00:00
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
2011-02-04 14:06:30 +00:00
this purpose you can use the generic
2016-11-15 17:14:43 +00:00
< tt > [within](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#within-instance_method)< / tt >
2011-02-04 14:06:30 +00:00
method. Optionally you can specify which kind of selector to use.
2010-07-10 15:10:54 +00:00
2012-01-04 00:00:27 +00:00
```ruby
within("li#employee") do
2016-10-04 18:10:29 +00:00
fill_in 'Name', with: 'Jimmy'
2012-01-04 00:00:27 +00:00
end
2010-07-10 15:10:54 +00:00
2016-10-26 19:24:51 +00:00
within(:xpath, ".//li[@id='employee']") do
2016-10-04 18:10:29 +00:00
fill_in 'Name', with: 'Jimmy'
2012-01-04 00:00:27 +00:00
end
```
2010-07-10 15:10:54 +00:00
There are special methods for restricting the scope to a specific fieldset,
2012-03-07 11:09:30 +00:00
identified by either an id or the text of the fieldset's legend tag, and to a
2010-07-10 15:10:54 +00:00
specific table, identified by either id or text of the table's caption tag.
2012-01-04 00:00:27 +00:00
```ruby
within_fieldset('Employee') do
2016-10-04 18:10:29 +00:00
fill_in 'Name', with: 'Jimmy'
2012-01-04 00:00:27 +00:00
end
2010-07-10 15:10:54 +00:00
2012-01-04 00:00:27 +00:00
within_table('Employee') do
2016-10-04 18:10:29 +00:00
fill_in 'Name', with: 'Jimmy'
2012-01-04 00:00:27 +00:00
end
```
2010-07-10 15:10:54 +00:00
2016-04-05 09:57:13 +00:00
### <a name="working-with-windows"></a>Working with windows
2014-04-08 21:28:16 +00:00
Capybara provides some methods to ease finding and switching windows:
```ruby
facebook_window = window_opened_by do
click_button 'Like'
end
within_window facebook_window do
find('#login_email').set('a@example.com')
find('#login_password').set('qwerty')
click_button 'Submit'
end
```
2016-04-05 09:57:13 +00:00
### <a name="scripting"></a>Scripting
2009-12-25 17:00:27 +00:00
2010-06-29 20:41:33 +00:00
In drivers which support it, you can easily execute JavaScript:
2012-01-04 00:00:27 +00:00
```ruby
page.execute_script("$('body').empty()")
```
2010-06-29 20:41:33 +00:00
2019-05-30 17:49:50 +00:00
For simple expressions, you can return the result of the script.
2009-12-25 17:00:27 +00:00
2012-01-04 00:00:27 +00:00
```ruby
result = page.evaluate_script('4 + 4');
```
2009-12-25 17:00:27 +00:00
2019-05-30 17:49:50 +00:00
For more complicated scripts you'll need to write them as one expression.
```ruby
result = page.evaluate_script(< < ~JS, 3, element)
(function(n, el){
var val = parseInt(el.value, 10);
return n+val;
})(arguments[0], arguments[1])
JS
```
2016-04-05 09:57:13 +00:00
### <a name="modals"></a>Modals
2013-04-01 22:41:55 +00:00
In drivers which support it, you can accept, dismiss and respond to alerts, confirms and prompts.
You can accept or dismiss alert messages by wrapping the code that produces an alert in a block:
```ruby
accept_alert do
click_link('Show Alert')
end
```
You can accept or dismiss a confirmation by wrapping it in a block, as well:
```ruby
dismiss_confirm do
click_link('Show Confirm')
end
```
2014-06-27 19:37:33 +00:00
You can accept or dismiss prompts as well, and also provide text to fill in for the response:
2013-04-01 22:41:55 +00:00
```ruby
2014-06-27 19:37:33 +00:00
accept_prompt(with: 'Linus Torvalds') do
2013-04-01 22:41:55 +00:00
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:
```ruby
2014-06-27 19:37:33 +00:00
message = accept_prompt(with: 'Linus Torvalds') do
2013-04-01 22:41:55 +00:00
click_link('Show Prompt About Linux')
end
expect(message).to eq('Who is the chief architect of Linux?')
```
2016-04-05 09:57:13 +00:00
### <a name="debugging"></a>Debugging
2009-12-25 17:00:27 +00:00
It can be useful to take a snapshot of the page as it currently is and take a
look at it:
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
```ruby
save_and_open_page
```
2009-11-18 23:00:10 +00:00
2012-01-08 18:53:31 +00:00
You can also retrieve the current state of the DOM as a string using
2016-11-15 17:14:43 +00:00
< tt > [page.html](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#html-instance_method)< / tt > .
2012-01-08 18:53:31 +00:00
```ruby
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.
2012-08-02 13:15:35 +00:00
Finally, in drivers that support it, you can save a screenshot:
```ruby
page.save_screenshot('screenshot.png')
```
2014-03-22 02:09:15 +00:00
Or have it save and automatically open:
```ruby
save_and_open_screenshot
```
2016-12-29 08:50:41 +00:00
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` .
2016-04-05 09:57:13 +00:00
## <a name="matching"></a>Matching
2013-02-24 17:14:54 +00:00
It is possible to customize how Capybara finds elements. At your disposal
are two options, `Capybara.exact` and `Capybara.match` .
2016-04-05 09:57:13 +00:00
### <a name="exactness"></a>Exactness
2013-02-24 17:14:54 +00:00
`Capybara.exact` and the `exact` option work together with the `is` expression
inside the XPath gem. When `exact` is true, all `is` expressions match exactly,
2013-03-08 23:35:31 +00:00
when it is false, they allow substring matches. Many of the selectors built into
2013-02-24 17:14:54 +00:00
Capybara use the `is` expression. This way you can specify whether you want to
allow substring matches or not. `Capybara.exact` is false by default.
For example:
```ruby
click_link("Password") # also matches "Password confirmation"
Capybara.exact = true
click_link("Password") # does not match "Password confirmation"
click_link("Password", exact: false) # can be overridden
```
2016-04-05 09:57:13 +00:00
### <a name="strategy"></a>Strategy
2013-02-24 17:14:54 +00:00
Using `Capybara.match` and the equivalent `match` option, you can control how
Capybara behaves when multiple elements all match a query. There are currently
four different strategies built into Capybara:
1. **first:** Just picks the first element that matches.
2. **one:** Raises an error if more than one element matches.
3. **smart:** If `exact` is `true` , raises an error if more than one element
matches, just like `one` . If `exact` is `false` , it will first try to find
an exact match. An error is raised if more than one element is found. If no
element is found, a new search is performed which allows partial matches. If
that search returns multiple matches, an error is raised.
4. **prefer_exact:** If multiple matches are found, some of which are exact,
2013-03-08 23:35:31 +00:00
and some of which are not, then the first exactly matching element is
2013-02-24 17:14:54 +00:00
returned.
The default for `Capybara.match` is `:smart` . To emulate the behaviour in
Capybara 2.0.x, set `Capybara.match` to `:one` . To emulate the behaviour in
Capybara 1.x, set `Capybara.match` to `:prefer_exact` .
2016-04-05 09:57:13 +00:00
## <a name="transactions-and-database-setup"></a>Transactions and database setup
2011-04-14 13:39:34 +00:00
2018-01-02 22:03:57 +00:00
**Note:** Rails 5.1+ "safely" shares the database connection between the app and test threads. Therefore,
2017-08-01 21:50:51 +00:00
if using Rails 5.1+ you SHOULD be able to ignore this section.
2012-01-03 13:40:51 +00:00
Some Capybara drivers need to run against an actual HTTP server. Capybara takes
care of this and starts one for you in the same process as your test, but on
another thread. Selenium is one of those drivers, whereas RackTest is not.
2012-03-07 11:09:30 +00:00
If you are using a SQL database, it is common to run every test in a
2012-01-03 13:40:51 +00:00
transaction, which is rolled back at the end of the test, rspec-rails does this
by default out of the box for example. Since transactions are usually not
shared across threads, this will cause data you have put into the database in
your test code to be invisible to Capybara.
Cucumber handles this by using truncation instead of transactions, i.e. they
empty out the entire database after each test. You can get the same behaviour
2015-11-18 20:41:57 +00:00
by using a gem such as [database_cleaner ](https://github.com/DatabaseCleaner/database_cleaner ).
2012-01-03 13:40:51 +00:00
2016-04-05 09:57:13 +00:00
## <a name="asynchronous-javascript-ajax-and-friends"></a>Asynchronous JavaScript (Ajax and friends)
2010-01-01 18:58:10 +00:00
When working with asynchronous JavaScript, you might come across situations
where you are attempting to interact with an element which is not yet present
2011-09-02 14:28:14 +00:00
on the page. Capybara automatically deals with this by waiting for elements
2010-01-01 18:58:10 +00:00
to appear on the page.
When issuing instructions to the DSL such as:
2012-01-04 00:00:27 +00:00
```ruby
click_link('foo')
click_link('bar')
2013-11-14 17:43:36 +00:00
expect(page).to have_content('baz')
2012-01-04 00:00:27 +00:00
```
2010-01-01 18:58:10 +00:00
2011-09-02 14:28:14 +00:00
If clicking on the *foo* link triggers an asynchronous process, such as
2011-03-14 14:27:46 +00:00
an Ajax request, which, when complete will add the *bar* link to the page,
2011-08-25 22:16:11 +00:00
clicking on the *bar* link would be expected to fail, since that link doesn't
2013-03-08 23:35:31 +00:00
exist yet. However Capybara is smart enough to retry finding the link for a
2010-01-01 18:58:10 +00:00
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):
2012-01-04 00:00:27 +00:00
```ruby
2015-04-14 20:56:30 +00:00
Capybara.default_max_wait_time = 5
2012-01-04 00:00:27 +00:00
```
2010-01-01 18:58:10 +00:00
2012-01-04 00:00:27 +00:00
Be aware that because of this behaviour, the following two statements are **not**
equivalent, and you should **always** use the latter!
2011-09-09 02:07:52 +00:00
2012-01-04 00:00:27 +00:00
```ruby
!page.has_xpath?('a')
page.has_no_xpath?('a')
```
2011-09-09 02:07:52 +00:00
The former would immediately fail because the content has not yet been removed.
Only the latter would wait for the asynchronous process to remove the content
from the page.
2016-02-23 14:27:54 +00:00
Capybara's RSpec matchers, however, are smart enough to handle either form.
2011-09-09 02:07:52 +00:00
The two following statements are functionally equivalent:
2012-01-04 00:00:27 +00:00
```ruby
2013-11-14 17:43:36 +00:00
expect(page).not_to have_xpath('a')
expect(page).to have_no_xpath('a')
2012-01-04 00:00:27 +00:00
```
2011-09-09 02:07:52 +00:00
2011-09-02 14:28:14 +00:00
Capybara's waiting behaviour is quite advanced, and can deal with situations
such as the following line of code:
2012-01-04 00:00:27 +00:00
```ruby
2013-11-14 17:43:36 +00:00
expect(find('#sidebar').find('h1')).to have_content('Something')
2012-01-04 00:00:27 +00:00
```
2011-09-02 14:28:14 +00:00
2012-01-04 00:00:27 +00:00
Even if JavaScript causes `#sidebar` to disappear off the page, Capybara
2011-09-02 14:28:14 +00:00
will automatically reload it and any elements it contains. So if an AJAX
2012-01-04 00:00:27 +00:00
request causes the contents of `#sidebar` to change, which would update
the text of the `h1` to "Something", and this happened, this test would
2011-09-02 14:28:14 +00:00
pass. If you do not want this behaviour, you can set
2012-01-04 00:00:27 +00:00
`Capybara.automatic_reload` to `false` .
2011-09-02 14:28:14 +00:00
2016-04-05 09:57:13 +00:00
## <a name="using-the-dsl-elsewhere"></a>Using the DSL elsewhere
2009-11-18 23:00:10 +00:00
2011-12-08 19:59:17 +00:00
You can mix the DSL into any context by including < tt > Capybara::DSL< / tt > :
2009-11-04 22:00:05 +00:00
2012-05-03 15:12:10 +00:00
2012-01-04 00:00:27 +00:00
```ruby
require 'capybara/dsl'
2009-11-18 23:00:10 +00:00
2012-01-04 00:00:27 +00:00
Capybara.default_driver = :webkit
2009-11-15 01:13:07 +00:00
2012-01-04 00:00:27 +00:00
module MyModule
include Capybara::DSL
2010-04-09 13:17:47 +00:00
2012-01-04 00:00:27 +00:00
def login!
2016-10-26 19:24:51 +00:00
within(:xpath, ".//form[@id='session']") do
2016-10-04 18:10:29 +00:00
fill_in 'Email', with: 'user@example.com'
fill_in 'Password', with: 'password'
2009-11-15 01:13:07 +00:00
end
2014-05-29 16:41:42 +00:00
click_button 'Sign in'
2012-01-04 00:00:27 +00:00
end
end
```
2009-11-15 01:13:07 +00:00
2012-05-03 15:12:10 +00:00
This enables its use in unsupported testing frameworks, and for general-purpose scripting.
2016-04-05 09:57:13 +00:00
## <a name="calling-remote-servers"></a>Calling remote servers
2010-02-03 12:18:20 +00:00
2010-10-06 19:07:47 +00:00
Normally Capybara expects to be testing an in-process Rack application, but you
2013-03-08 23:35:31 +00:00
can also use it to talk to a web server running anywhere on the internet, by
2010-10-06 19:07:47 +00:00
setting app_host:
2010-02-03 12:18:20 +00:00
2012-01-04 00:00:27 +00:00
```ruby
Capybara.current_driver = :selenium
Capybara.app_host = 'http://www.google.com'
...
visit('/')
```
2010-02-03 12:18:20 +00:00
2012-01-04 00:00:27 +00:00
**Note**: the default driver (`:rack_test`) does not support running
2011-03-14 14:27:46 +00:00
against a remote server. With drivers that support it, you can also visit any
URL directly:
2010-02-05 18:54:56 +00:00
2012-01-04 00:00:27 +00:00
```ruby
visit('http://www.google.com')
```
2010-02-05 18:54:56 +00:00
2010-10-06 19:07:47 +00:00
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:
2010-02-05 18:54:56 +00:00
2012-01-04 00:00:27 +00:00
```ruby
Capybara.run_server = false
```
2010-02-05 18:54:56 +00:00
2016-06-11 06:52:47 +00:00
## <a name="using-sessions"></a>Using sessions
2016-04-22 17:54:57 +00:00
2016-07-11 21:27:37 +00:00
Capybara manages named sessions (:default if not specified) allowing multiple sessions using the same driver and test app instance to be interacted with.
2016-04-22 17:54:57 +00:00
A new session will be created using the current driver if a session with the given name using the current driver and test app instance is not found.
2016-07-11 21:29:00 +00:00
### Named sessions
2016-07-11 21:27:37 +00:00
To perform operations in a different session and then revert to the previous session
2016-04-22 17:54:57 +00:00
```ruby
Capybara.using_session("Bob's session") do
#do something in Bob's browser session
end
#reverts to previous session
```
To permanently switch the current session to a different session
```ruby
Capybara.session_name = "some other session"
2017-11-01 13:55:50 +00:00
```
2016-04-22 17:54:57 +00:00
2016-07-11 21:29:00 +00:00
### <a name="using-sessions-manually"></a>Using sessions manually
2009-11-15 01:13:07 +00:00
2011-03-14 14:27:46 +00:00
For ultimate control, you can instantiate and use a
2016-11-15 17:14:43 +00:00
[Session ](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session )
2011-03-14 14:27:46 +00:00
manually.
2009-11-15 01:13:07 +00:00
2012-01-04 00:00:27 +00:00
```ruby
require 'capybara'
2009-11-15 01:13:07 +00:00
2012-01-04 00:00:27 +00:00
session = Capybara::Session.new(:webkit, my_rack_app)
2016-09-23 00:11:07 +00:00
session.within("form#session") do
2016-10-04 18:10:29 +00:00
session.fill_in 'Email', with: 'user@example.com'
session.fill_in 'Password', with: 'password'
2012-01-04 00:00:27 +00:00
end
2014-05-29 16:41:42 +00:00
session.click_button 'Sign in'
2012-01-04 00:00:27 +00:00
```
2009-11-15 01:13:07 +00:00
2016-04-05 09:57:13 +00:00
## <a name="xpath-css-and-selectors"></a>XPath, CSS and selectors
2009-11-26 22:48:18 +00:00
Capybara does not try to guess what kind of selector you are going to give it,
2011-02-04 14:06:30 +00:00
and will always use CSS by default. If you want to use XPath, you'll need to
do:
2009-12-12 12:37:29 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2016-10-26 19:24:51 +00:00
within(:xpath, './/ul/li') { ... }
find(:xpath, './/ul/li').text
find(:xpath, './/li[contains(.//a[@href = "#"]/text(), "foo")]').value
2012-01-04 00:00:27 +00:00
```
2009-11-26 22:48:18 +00:00
2010-07-16 20:21:35 +00:00
Alternatively you can set the default selector to XPath:
2009-11-26 22:48:18 +00:00
2012-01-04 00:00:27 +00:00
```ruby
Capybara.default_selector = :xpath
2016-10-26 19:24:51 +00:00
find('.//ul/li').text
2012-01-04 00:00:27 +00:00
```
2009-11-26 22:48:18 +00:00
2019-05-29 23:09:32 +00:00
Capybara provides a number of other built-in selector types. The full list, along
with applicable filters, can be seen at [built-in selectors ](https://www.rubydoc.info/github/teamcapybara/capybara/Capybara/Selector )
Capybara also allows you to add custom selectors, which can be very useful if you
find yourself using the same kinds of selectors very often. The examples below are very
simple, and there are many available features not demonstrated. For more in-depth examples
please see Capybaras built-in selector definitions.
2010-08-27 19:07:26 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2019-05-29 23:09:32 +00:00
Capybara.add_selector(:my_attribute) do
xpath { |id| XPath.descendant[XPath.attr(:my_attribute) == id.to_s] }
2012-01-04 00:00:27 +00:00
end
2010-10-22 11:29:08 +00:00
2012-01-04 00:00:27 +00:00
Capybara.add_selector(:row) do
xpath { |num| ".//tbody/tr[#{num}]" }
end
2010-08-27 19:07:26 +00:00
2012-01-04 00:00:27 +00:00
Capybara.add_selector(:flash_type) do
css { |type| "#flash.#{type}" }
end
```
2011-09-29 20:04:51 +00:00
2010-10-22 11:29:08 +00:00
The block given to xpath 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:
2010-08-27 19:07:26 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2019-05-29 23:09:32 +00:00
find(:my_attribute, 'post_123') # find element with matching attribute
find(:row, 3) # find 3rd row in table body
find(:flash_type, :notice) # find element with id of 'flash' and class of 'notice'
2012-01-04 00:00:27 +00:00
```
2010-08-27 19:07:26 +00:00
2016-04-05 09:57:13 +00:00
## <a name="beware-the-xpath--trap"></a>Beware the XPath // trap
2010-07-10 15:15:57 +00:00
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:
2012-01-04 00:00:27 +00:00
```ruby
page.find(:xpath, '//body').all(:xpath, '//script')
```
2010-07-10 15:15:57 +00:00
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":
2012-01-04 00:00:27 +00:00
```ruby
page.find(:xpath, '//body').all(:xpath, './/script')
```
2010-07-11 11:10:57 +00:00
The same thing goes for within:
2012-01-04 00:00:27 +00:00
```ruby
within(:xpath, '//body') do
page.find(:xpath, './/script')
within(:xpath, './/table/tbody') do
...
end
end
```
2010-07-11 11:10:57 +00:00
2016-04-05 09:57:13 +00:00
## <a name="configuring-and-adding-drivers"></a>Configuring and adding drivers
2010-09-16 19:55:57 +00:00
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
2013-09-04 20:06:52 +00:00
drivers. This is how to override the selenium driver configuration to use chrome:
2010-09-16 19:55:57 +00:00
2012-01-04 00:00:27 +00:00
```ruby
Capybara.register_driver :selenium do |app|
Capybara::Selenium::Driver.new(app, :browser => :chrome)
end
```
2010-09-16 19:55:57 +00:00
2013-10-20 18:16:00 +00:00
However, it's also possible to give this configuration a different name.
2010-09-16 19:55:57 +00:00
2012-01-04 00:00:27 +00:00
```ruby
2018-08-14 17:34:17 +00:00
# Note: Capybara registers this by default
2012-01-04 00:00:27 +00:00
Capybara.register_driver :selenium_chrome do |app|
Capybara::Selenium::Driver.new(app, :browser => :chrome)
end
```
2010-09-16 19:55:57 +00:00
2013-09-04 20:06:52 +00:00
Then tests can switch between using different browsers effortlessly:
```ruby
Capybara.current_driver = :selenium_chrome
```
2010-09-16 19:55:57 +00:00
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.
2015-12-30 04:59:18 +00:00
The [Selenium wiki ](https://github.com/SeleniumHQ/selenium/wiki/Ruby-Bindings ) has
2011-01-07 15:44:21 +00:00
additional info about how the underlying driver can be configured.
2016-04-05 09:57:13 +00:00
## <a name="gotchas"></a>Gotchas:
2009-11-15 01:13:07 +00:00
2010-07-16 20:21:35 +00:00
* 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.
2009-11-04 22:00:05 +00:00
2012-01-04 00:00:27 +00:00
* Access to Rails specific stuff (such as `controller` ) is unavailable,
2009-11-19 22:14:34 +00:00
since we're not using Rails' integration testing.
2009-11-18 23:15:46 +00:00
2010-07-17 11:21:23 +00:00
* Freezing time: It's common practice to mock out the Time so that features
2015-04-14 21:41:01 +00:00
that depend on the current Date work as expected. This can be problematic on
ruby/platform combinations that don't support access to a monotonic process clock,
2011-03-14 14:27:46 +00:00
since Capybara's Ajax timing uses the system time, resulting in Capybara
2010-07-17 11:21:23 +00:00
never timing out and just hanging when a failure occurs. It's still possible to
2012-02-10 11:53:14 +00:00
use gems which allow you to travel in time, rather than freeze time.
2015-11-18 20:41:57 +00:00
One such gem is [Timecop ](https://github.com/travisjeffery/timecop ).
2010-07-17 11:21:23 +00:00
2010-11-22 10:53:53 +00:00
* When using Rack::Test, beware if attempting to visit absolute URLs. For
2012-01-04 00:00:27 +00:00
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` .
2010-11-22 10:53:53 +00:00
2015-07-21 21:48:14 +00:00
* Server errors will only be raised in the session that initiates the server thread. If you
are testing for specific server errors and using multiple sessions make sure to test for the
errors using the initial session (usually :default)
2018-03-31 21:43:58 +00:00
## <a name="threadsafe"></a>"Threadsafe" mode
2016-12-15 17:04:01 +00:00
In normal mode most of Capybara's configuration options are global settings which can cause issues
if using multiple sessions and wanting to change a setting for only one of the sessions. To provide
support for this type of usage Capybara now provides a "threadsafe" mode which can be enabled by setting
2017-11-01 13:58:47 +00:00
```ruby
Capybara.threadsafe = true
```
2016-12-15 17:04:01 +00:00
This setting can only be changed before any sessions have been created. In "threadsafe" mode the following
behaviors of Capybara change
* Most options can now be set on a session. These can either be set at session creation time or after, and
default to the global options at the time of session creation. Options which are NOT session specific are
`app` , `reuse_server` , `default_driver` , `javascript_driver` , and (obviously) `threadsafe` . Any drivers and servers
registered through `register_driver` and `register_server` are also global.
2017-11-01 13:58:47 +00:00
```ruby
my_session = Capybara::Session.new(:driver, some_app) do |config|
config.automatic_label_click = true # only set for my_session
end
my_session.config.default_max_wait_time = 10 # only set for my_session
Capybara.default_max_wait_time = 2 # will not change the default_max_wait in my_session
```
2016-12-15 17:04:01 +00:00
2017-05-23 09:20:26 +00:00
* `current_driver` and `session_name` are thread specific. This means that `using_session` and
2016-12-15 17:04:01 +00:00
`using_driver` also only affect the current thread.
2016-04-05 09:57:13 +00:00
## <a name="development"></a>Development
2011-12-21 17:06:04 +00:00
To set up a development environment, simply do:
2012-01-04 00:00:27 +00:00
```bash
bundle install
2018-01-02 22:03:57 +00:00
bundle exec rake # run the test suite with Firefox - requires `geckodriver` to be installed
bundle exec rake spec_chrome # run the test suite with Chrome - require `chromedriver` to be installed
2012-01-04 00:00:27 +00:00
```
2012-09-21 15:03:05 +00:00
See
2016-11-15 17:14:43 +00:00
[CONTRIBUTING.md ](https://github.com/teamcapybara/capybara/blob/master/CONTRIBUTING.md )
2012-09-21 15:03:05 +00:00
for how to send issues and pull requests.