{"id":27567733,"url":"https://github.com/jnicklas/capybara","last_synced_at":"2025-04-20T21:01:05.009Z","repository":{"id":37484435,"uuid":"361310","full_name":"teamcapybara/capybara","owner":"teamcapybara","description":"Acceptance test framework for web applications","archived":false,"fork":false,"pushed_at":"2024-08-16T08:12:16.000Z","size":12796,"stargazers_count":10075,"open_issues_count":59,"forks_count":1456,"subscribers_count":220,"default_branch":"master","last_synced_at":"2025-04-15T14:54:47.612Z","etag":null,"topics":["hacktoberfest"],"latest_commit_sha":null,"homepage":"http://teamcapybara.github.io/capybara/","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/teamcapybara.png","metadata":{"files":{"readme":"README.md","changelog":"History.md","contributing":"CONTRIBUTING.md","funding":null,"license":"License.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2009-11-04T22:19:17.000Z","updated_at":"2025-04-09T15:01:44.000Z","dependencies_parsed_at":"2023-07-12T16:12:18.958Z","dependency_job_id":"afec9d89-8ede-41d3-9d85-b4cb4f1a4204","html_url":"https://github.com/teamcapybara/capybara","commit_stats":{"total_commits":3550,"total_committers":414,"mean_commits":8.57487922705314,"dds":0.512112676056338,"last_synced_commit":"0480f90168a40780d1398c75031a255c1819dce8"},"previous_names":["jnicklas/capybara"],"tags_count":153,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/teamcapybara%2Fcapybara","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/teamcapybara%2Fcapybara/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/teamcapybara%2Fcapybara/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/teamcapybara%2Fcapybara/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/teamcapybara","download_url":"https://codeload.github.com/teamcapybara/capybara/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249961531,"owners_count":21352091,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["hacktoberfest"],"created_at":"2025-04-20T21:00:52.453Z","updated_at":"2025-04-20T21:01:04.965Z","avatar_url":"https://github.com/teamcapybara.png","language":"Ruby","readme":"# Capybara\n\n[![Build Status](https://github.com/teamcapybara/capybara/actions/workflows/build.yml/badge.svg)](https://github.com/teamcapybara/capybara/actions/workflows/build.yml)\n[![Code Climate](https://codeclimate.com/github/teamcapybara/capybara.svg)](https://codeclimate.com/github/teamcapybara/capybara)\n[![Coverage Status](https://coveralls.io/repos/github/teamcapybara/capybara/badge.svg?branch=master)](https://coveralls.io/github/teamcapybara/capybara?branch=master)\n\nCapybara helps you test web applications by simulating how a real user would\ninteract with your app. It is agnostic about the driver running your tests and\ncomes with Rack::Test and Selenium support built in. WebKit is supported\nthrough an external gem.\n\n## Support Capybara\n\nIf you and/or your company find value in Capybara and would like to contribute financially to its ongoing maintenance and development, please visit\n\u003ca href=\"https://www.patreon.com/capybara\"\u003ePatreon\u003c/a\u003e\n\n\n**Need help?** Ask on the discussions (please do not open an issue): https://github.com/orgs/teamcapybara/discussions/categories/q-a\n\n## Table of contents\n\n- [Key benefits](#key-benefits)\n- [Setup](#setup)\n- [Using Capybara with Cucumber](#using-capybara-with-cucumber)\n- [Using Capybara with RSpec](#using-capybara-with-rspec)\n- [Using Capybara with Test::Unit](#using-capybara-with-testunit)\n- [Using Capybara with Minitest](#using-capybara-with-minitest)\n- [Using Capybara with Minitest::Spec](#using-capybara-with-minitestspec)\n- [Drivers](#drivers)\n    - [Selecting the Driver](#selecting-the-driver)\n    - [RackTest](#racktest)\n    - [Selenium](#selenium)\n- [The DSL](#the-dsl)\n    - [Navigating](#navigating)\n    - [Clicking links and buttons](#clicking-links-and-buttons)\n    - [Interacting with forms](#interacting-with-forms)\n    - [Querying](#querying)\n    - [Finding](#finding)\n    - [Scoping](#scoping)\n    - [Working with windows](#working-with-windows)\n    - [Scripting](#scripting)\n    - [Modals](#modals)\n    - [Debugging](#debugging)\n- [Selectors](#selectors)\n    - [Name](#selectors-name)\n    - [Locator](#selectors-locator)\n    - [Filters](#selectors-filters)\n- [Matching](#matching)\n    - [Exactness](#exactness)\n    - [Strategy](#strategy)\n- [Transactions and database setup](#transactions-and-database-setup)\n- [Asynchronous JavaScript (Ajax and friends)](#asynchronous-javascript-ajax-and-friends)\n- [Using the DSL elsewhere](#using-the-dsl-elsewhere)\n- [Calling remote servers](#calling-remote-servers)\n- [Using sessions](#using-sessions)\n    - [Named sessions](#named-sessions)\n    - [Using sessions manually](#using-sessions-manually)\n- [XPath, CSS and selectors](#xpath-css-and-selectors)\n- [Beware the XPath // trap](#beware-the-xpath--trap)\n- [Configuring and adding drivers](#configuring-and-adding-drivers)\n- [Gotchas:](#gotchas)\n- [\"Threadsafe\" mode](#threadsafe-mode)\n- [Development](#development)\n\n## \u003ca name=\"key-benefits\"\u003e\u003c/a\u003eKey benefits\n\n- **No setup** necessary for Rails and Rack application. Works out of the box.\n- **Intuitive API** which mimics the language an actual user would use.\n- **Switch the backend** your tests run against from fast headless mode\n  to an actual browser with no changes to your tests.\n- **Powerful synchronization** features mean you never have to manually wait\n  for asynchronous processes to complete.\n\n## \u003ca name=\"setup\"\u003e\u003c/a\u003eSetup\n\nCapybara requires Ruby 3.0.0 or later. To install, add this line to your\n`Gemfile` and run `bundle install`:\n\n```ruby\ngem 'capybara'\n```\n\nIf the application that you are testing is a Rails app, add this line to your test helper file:\n\n```ruby\nrequire 'capybara/rails'\n```\n\nIf the application that you are testing is a Rack app, but not Rails, set Capybara.app to your Rack app:\n\n```ruby\nCapybara.app = MyRackApp\n```\n\nIf you need to test JavaScript, or if your app interacts with (or is located at)\na 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\nwant to swap the \"server\" used to launch your app to Puma in order to match Rails defaults.\n\n```ruby\nCapybara.server = :puma # Until your setup is working\nCapybara.server = :puma, { Silent: true } # To clean up your test output\n```\n\n## \u003ca name=\"using-capybara-with-cucumber\"\u003e\u003c/a\u003eUsing Capybara with Cucumber\n\nThe `cucumber-rails` gem comes with Capybara support built-in. If you\nare not using Rails, manually load the `capybara/cucumber` module:\n\n```ruby\nrequire 'capybara/cucumber'\nCapybara.app = MyRackApp\n```\n\nYou can use the Capybara DSL in your steps, like so:\n\n```ruby\nWhen /I sign in/ do\n  within(\"#session\") do\n    fill_in 'Email', with: 'user@example.com'\n    fill_in 'Password', with: 'password'\n  end\n  click_button 'Sign in'\nend\n```\n\nYou can switch to the `Capybara.javascript_driver` (`:selenium`\nby default) by tagging scenarios (or features) with `@javascript`:\n\n```ruby\n@javascript\nScenario: do something Ajaxy\n  When I click the Ajax link\n  ...\n```\n\nThere are also explicit tags for each registered driver set up for you (`@selenium`, `@rack_test`, etc).\n\n## \u003ca name=\"using-capybara-with-rspec\"\u003e\u003c/a\u003eUsing Capybara with RSpec\n\nLoad RSpec 3.5+ support by adding the following line (typically to your\n`spec_helper.rb` file):\n\n```ruby\nrequire 'capybara/rspec'\n```\n\nIf you are using Rails, put your Capybara specs in `spec/features` or `spec/system` (only works if\n[you have it configured in RSpec](https://rspec.info/features/6-0/rspec-rails/directory-structure/))\nand if you have your Capybara specs in a different directory, then tag the example groups with\n`type: :feature` or `type: :system` depending on which type of test you're writing.\n\nIf you are using Rails system specs please see [their documentation](https://rspec.info/features/6-0/rspec-rails/system-specs/system-specs)\nfor selecting the driver you wish to use.\n\nIf you are not using Rails, tag all the example groups in which you want to use\nCapybara with `type: :feature`.\n\nYou can now write your specs like so:\n\n```ruby\ndescribe \"the signin process\", type: :feature do\n  before :each do\n    User.create(email: 'user@example.com', password: 'password')\n  end\n\n  it \"signs me in\" do\n    visit '/sessions/new'\n    within(\"#session\") do\n      fill_in 'Email', with: 'user@example.com'\n      fill_in 'Password', with: 'password'\n    end\n    click_button 'Sign in'\n    expect(page).to have_content 'Success'\n  end\nend\n```\n\nUse `js: true` to switch to the `Capybara.javascript_driver`\n(`:selenium` by default), or provide a `:driver` option to switch\nto one specific driver. For example:\n\n```ruby\ndescribe 'some stuff which requires js', js: true do\n  it 'will use the default js driver'\n  it 'will switch to one specific driver', driver: :selenium\nend\n```\n\nCapybara also comes with a built in DSL for creating descriptive acceptance tests:\n\n```ruby\nfeature \"Signing in\" do\n  background do\n    User.create(email: 'user@example.com', password: 'caplin')\n  end\n\n  scenario \"Signing in with correct credentials\" do\n    visit '/sessions/new'\n    within(\"#session\") do\n      fill_in 'Email', with: 'user@example.com'\n      fill_in 'Password', with: 'caplin'\n    end\n    click_button 'Sign in'\n    expect(page).to have_content 'Success'\n  end\n\n  given(:other_user) { User.create(email: 'other@example.com', password: 'rous') }\n\n  scenario \"Signing in as another user\" do\n    visit '/sessions/new'\n    within(\"#session\") do\n      fill_in 'Email', with: other_user.email\n      fill_in 'Password', with: other_user.password\n    end\n    click_button 'Sign in'\n    expect(page).to have_content 'Invalid email or password'\n  end\nend\n```\n\n`feature` is in fact just an alias for `describe ..., type: :feature`,\n`background` is an alias for `before`, `scenario` for `it`, and\n`given`/`given!` aliases for `let`/`let!`, respectively.\n\nFinally, Capybara matchers are also supported in view specs:\n\n```ruby\nRSpec.describe \"todos/show.html.erb\", type: :view do\n  it \"displays the todo title\" do\n    assign :todo, Todo.new(title: \"Buy milk\")\n\n    render\n\n    expect(rendered).to have_css(\"header h1\", text: \"Buy milk\")\n  end\nend\n```\n\n**Note: When you require 'capybara/rspec' proxy methods are installed to work around name collisions between Capybara::DSL methods\n  `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'**\n\n## \u003ca name=\"using-capybara-with-testunit\"\u003e\u003c/a\u003eUsing Capybara with Test::Unit\n\n* If you are using `Test::Unit`, define a base class for your Capybara tests\n  like so:\n\n    ```ruby\n    require 'capybara/dsl'\n\n    class CapybaraTestCase \u003c Test::Unit::TestCase\n      include Capybara::DSL\n\n      def teardown\n        Capybara.reset_sessions!\n        Capybara.use_default_driver\n      end\n    end\n    ```\n\n## \u003ca name=\"using-capybara-with-minitest\"\u003e\u003c/a\u003eUsing Capybara with Minitest\n\n* If you are using Rails system tests please see their documentation for information on selecting the driver you wish to use.\n\n* If you are using Rails, but not using Rails system tests, add the following code in your `test_helper.rb`\n    file to make Capybara available in all test cases deriving from\n    `ActionDispatch::IntegrationTest`:\n\n    ```ruby\n    require 'capybara/rails'\n    require 'capybara/minitest'\n\n    class ActionDispatch::IntegrationTest\n      # Make the Capybara DSL available in all integration tests\n      include Capybara::DSL\n      # Make `assert_*` methods behave like Minitest assertions\n      include Capybara::Minitest::Assertions\n\n      # Reset sessions and driver between tests\n      teardown do\n        Capybara.reset_sessions!\n        Capybara.use_default_driver\n      end\n    end\n    ```\n\n* If you are not using Rails, define a base class for your Capybara tests like\n  so:\n\n    ```ruby\n    require 'capybara/minitest'\n\n    class CapybaraTestCase \u003c Minitest::Test\n      include Capybara::DSL\n      include Capybara::Minitest::Assertions\n\n      def teardown\n        Capybara.reset_sessions!\n        Capybara.use_default_driver\n      end\n    end\n    ```\n\n    Remember to call `super` in any subclasses that override\n    `teardown`.\n\nTo switch the driver, set `Capybara.current_driver`. For instance,\n\n```ruby\nclass BlogTest \u003c ActionDispatch::IntegrationTest\n  setup do\n    Capybara.current_driver = Capybara.javascript_driver # :selenium by default\n  end\n\n  test 'shows blog posts' do\n    # ... this test is run with Selenium ...\n  end\nend\n```\n\n## \u003ca name=\"using-capybara-with-minitestspec\"\u003e\u003c/a\u003eUsing Capybara with Minitest::Spec\n\nFollow the above instructions for Minitest and additionally require capybara/minitest/spec\n\n```ruby\npage.must_have_content('Important!')\n```\n\n## \u003ca name=\"drivers\"\u003e\u003c/a\u003eDrivers\n\nCapybara uses the same DSL to drive a variety of browser and headless drivers.\n\n### \u003ca name=\"selecting-the-driver\"\u003e\u003c/a\u003eSelecting the Driver\n\nBy default, Capybara uses the `:rack_test` driver, which is fast but limited: it\ndoes not support JavaScript, nor is it able to access HTTP resources outside of\nyour Rack application, such as remote APIs and OAuth services. To get around\nthese limitations, you can set up a different default driver for your features.\nFor example, if you'd prefer to run everything in Selenium, you could do:\n\n```ruby\nCapybara.default_driver = :selenium # :selenium_chrome and :selenium_chrome_headless are also registered\n```\n\nHowever, if you are using RSpec or Cucumber (and your app runs correctly without JS),\nyou may instead want to consider leaving the faster `:rack_test` as the __default_driver__, and\nmarking only those tests that require a JavaScript-capable driver using `js: true` or\n`@javascript`, respectively.  By default, JavaScript tests are run using the\n`:selenium` driver. You can change this by setting\n`Capybara.javascript_driver`.\n\nYou can also change the driver temporarily (typically in the Before/setup and\nAfter/teardown blocks):\n\n```ruby\nCapybara.current_driver = :selenium # temporarily select different driver\n# tests here\nCapybara.use_default_driver       # switch back to default driver\n```\n\n**Note**: switching the driver creates a new session, so you may not be able to\nswitch in the middle of a test.\n\n### \u003ca name=\"racktest\"\u003e\u003c/a\u003eRackTest\n\nRackTest is Capybara's default driver. It is written in pure Ruby and does not\nhave any support for executing JavaScript. Since the RackTest driver interacts\ndirectly with Rack interfaces, it does not require a server to be started.\nHowever, this means that if your application is not a Rack application (Rails,\nSinatra and most other Ruby frameworks are Rack applications) then you cannot\nuse this driver. Furthermore, you cannot use the RackTest driver to test a\nremote application, or to access remote URLs (e.g., redirects to external\nsites, external APIs, or OAuth services) that your application might interact\nwith.\n\n[capybara-mechanize](https://github.com/jeroenvandijk/capybara-mechanize)\nprovides a similar driver that can access remote servers.\n\nRackTest can be configured with a set of headers like this:\n\n```ruby\nCapybara.register_driver :rack_test do |app|\n  Capybara::RackTest::Driver.new(app, headers: { 'HTTP_USER_AGENT' =\u003e 'Capybara' })\nend\n```\n\nSee the section on adding and configuring drivers.\n\n### \u003ca name=\"selenium\"\u003e\u003c/a\u003eSelenium\n\nCapybara supports [Selenium 3.5+\n(Webdriver)](https://www.seleniumhq.org/projects/webdriver/).\nIn order to use Selenium, you'll need to install the `selenium-webdriver` gem,\nand add it to your Gemfile if you're using bundler.\n\nCapybara pre-registers a number of named drivers that use Selenium - they are:\n\n  * :selenium                 =\u003e Selenium driving Firefox\n  * :selenium_headless        =\u003e Selenium driving Firefox in a headless configuration\n  * :selenium_chrome          =\u003e Selenium driving Chrome\n  * :selenium_chrome_headless =\u003e Selenium driving Chrome in a headless configuration\n\nThese should work (with relevant software installation) in a local desktop configuration but you may\nneed to customize them if using in a CI environment where additional options may need to be passed\nto the browsers.  See the section on adding and configuring drivers.\n\n\n**Note**: drivers which run the server in a different thread may not share the\nsame transaction as your tests, causing data not to be shared between your test\nand test server, see [Transactions and database setup](#transactions-and-database-setup) below.\n\n## \u003ca name=\"the-dsl\"\u003e\u003c/a\u003eThe DSL\n\n*A complete reference is available at\n[rubydoc.info](http://rubydoc.info/github/teamcapybara/capybara/master)*.\n\n**Note: By default Capybara will only locate visible elements. This is because\n a real user would not be able to interact with non-visible elements.**\n\n**Note**: All searches in Capybara are *case sensitive*. This is because\nCapybara heavily uses XPath, which doesn't support case insensitivity.\n\n### \u003ca name=\"navigating\"\u003e\u003c/a\u003eNavigating\n\nYou can use the\n\u003ctt\u003e[visit](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#visit-instance_method)\u003c/tt\u003e\nmethod to navigate to other pages:\n\n```ruby\nvisit('/projects')\nvisit(post_comments_path(post))\n```\n\nThe visit method only takes a single parameter, the request method is **always**\nGET.\n\nYou can get the [current path](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#current_path-instance_method)\nof 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:\n\n```ruby\nexpect(page).to have_current_path(post_comments_path(post))\n```\n\n**Note**: You can also assert the current path by testing the value of\n`current_path` directly. However, using the `have_current_path` matcher is\nsafer since it uses Capybara's [waiting behaviour](#asynchronous-javascript-ajax-and-friends)\nto ensure that preceding actions (such as a `click_link`) have completed.\n\n### \u003ca name=\"clicking-links-and-buttons\"\u003e\u003c/a\u003eClicking links and buttons\n\n*Full reference: [Capybara::Node::Actions](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Actions)*\n\nYou can interact with the webapp by following links and buttons. Capybara\nautomatically follows any redirects, and submits forms associated with buttons.\n\n```ruby\nclick_link('id-of-link')\nclick_link('Link Text')\nclick_button('Save')\nclick_on('Link Text') # clicks on either links or buttons\nclick_on('Button Value')\n```\n\n### \u003ca name=\"interacting-with-forms\"\u003e\u003c/a\u003eInteracting with forms\n\n*Full reference: [Capybara::Node::Actions](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Actions)*\n\nThere are a number of tools for interacting with form elements:\n\n```ruby\nfill_in('First Name', with: 'John')\nfill_in('Password', with: 'Seekrit')\nfill_in('Description', with: 'Really Long Text...')\nchoose('A Radio Button')\ncheck('A Checkbox')\nuncheck('A Checkbox')\nattach_file('Image', '/path/to/image.jpg')\nselect('Option', from: 'Select Box')\n```\n\n### \u003ca name=\"querying\"\u003e\u003c/a\u003eQuerying\n\n*Full reference: [Capybara::Node::Matchers](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Matchers)*\n\nCapybara has a rich set of options for querying the page for the existence of\ncertain elements, and working with and manipulating those elements.\n\n```ruby\npage.has_selector?('table tr')\npage.has_selector?(:xpath, './/table/tr')\n\npage.has_xpath?('.//table/tr')\npage.has_css?('table tr.foo')\npage.has_content?('foo')\n```\n\n**Note:** The negative forms like `has_no_selector?` are different from `not\nhas_selector?`. Read the section on asynchronous JavaScript for an explanation.\n\nYou can use these with RSpec's magic matchers:\n\n```ruby\nexpect(page).to have_selector('table tr')\nexpect(page).to have_selector(:xpath, './/table/tr')\n\nexpect(page).to have_xpath('.//table/tr')\nexpect(page).to have_css('table tr.foo')\nexpect(page).to have_content('foo')\n```\n\n### \u003ca name=\"finding\"\u003e\u003c/a\u003eFinding\n\n_Full reference: [Capybara::Node::Finders](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders)_\n\nYou can also find specific elements, in order to manipulate them:\n\n```ruby\nfind_field('First Name').value\nfind_field(id: 'my_field').value\nfind_link('Hello', :visible =\u003e :all).visible?\nfind_link(class: ['some_class', 'some_other_class'], :visible =\u003e :all).visible?\n\nfind_button('Send').click\nfind_button(value: '1234').click\n\nfind(:xpath, \".//table/tr\").click\nfind(\"#overlay\").find(\"h1\").click\nall('a').each { |a| a[:href] }\n```\n\nIf 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.\nIf 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).\n\n```ruby\nfind_field('First Name'){ |el| el['data-xyz'] == '123' }\nfind(\"#img_loading\"){ |img| img['complete'] == true }\n```\n\n**Note**: `find` will wait for an element to appear on the page, as explained in the\nAjax section. If the element does not appear it will raise an error.\n\nThese elements all have all the Capybara DSL methods available, so you can restrict them\nto specific parts of the page:\n\n```ruby\nfind('#navigation').click_link('Home')\nexpect(find('#navigation')).to have_button('Sign out')\n```\n\n### \u003ca name=\"scoping\"\u003e\u003c/a\u003eScoping\n\nCapybara makes it possible to restrict certain actions, such as interacting with\nforms or clicking links and buttons, to within a specific area of the page. For\nthis purpose you can use the generic\n\u003ctt\u003e[within](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#within-instance_method)\u003c/tt\u003e\nmethod. Optionally you can specify which kind of selector to use.\n\n```ruby\nwithin(\"li#employee\") do\n  fill_in 'Name', with: 'Jimmy'\nend\n\nwithin(:xpath, \".//li[@id='employee']\") do\n  fill_in 'Name', with: 'Jimmy'\nend\n```\n\nThere are special methods for restricting the scope to a specific fieldset,\nidentified by either an id or the text of the fieldset's legend tag, and to a\nspecific table, identified by either id or text of the table's caption tag.\n\n```ruby\nwithin_fieldset('Employee') do\n  fill_in 'Name', with: 'Jimmy'\nend\n\nwithin_table('Employee') do\n  fill_in 'Name', with: 'Jimmy'\nend\n```\n\n### \u003ca name=\"working-with-windows\"\u003e\u003c/a\u003eWorking with windows\n\nCapybara provides some methods to ease finding and switching windows:\n\n```ruby\nfacebook_window = window_opened_by do\n  click_button 'Like'\nend\nwithin_window facebook_window do\n  find('#login_email').set('a@example.com')\n  find('#login_password').set('qwerty')\n  click_button 'Submit'\nend\n```\n\n### \u003ca name=\"scripting\"\u003e\u003c/a\u003eScripting\n\nIn drivers which support it, you can easily execute JavaScript:\n\n```ruby\npage.execute_script(\"$('body').empty()\")\n```\n\nFor simple expressions, you can return the result of the script.\n\n```ruby\nresult = page.evaluate_script('4 + 4');\n```\n\nFor more complicated scripts you'll need to write them as one expression.\n\n```ruby\nresult = page.evaluate_script(\u003c\u003c~JS, 3, element)\n  (function(n, el){\n    var val = parseInt(el.value, 10);\n    return n+val;\n  })(arguments[0], arguments[1])\nJS\n```\n\n### \u003ca name=\"modals\"\u003e\u003c/a\u003eModals\n\nIn drivers which support it, you can accept, dismiss and respond to alerts, confirms, and prompts.\n\nYou can accept alert messages by wrapping the code that produces an alert in a block:\n\n```ruby\naccept_alert 'optional text or regex' do\n  click_link('Show Alert')\nend\n```\n\nYou can accept or dismiss a confirmation by wrapping it in a block, as well:\n\n```ruby\naccept_confirm 'optional text' do\n  click_link('Show Confirm')\nend\n```\n\n```ruby\ndismiss_confirm 'optional text' do\n  click_link('Show Confirm')\nend\n```\n\nYou can accept or dismiss prompts as well, and also provide text to fill in for the response:\n\n```ruby\naccept_prompt('optional text', with: 'Linus Torvalds') do\n  click_link('Show Prompt About Linux')\nend\n```\n\n```ruby\ndismiss_prompt('optional text') do\n  click_link('Show Prompt About Linux')\nend\n```\n\nAll modal methods return the message that was presented. So, you can access the prompt message\nby assigning the return to a variable:\n\n```ruby\nmessage = accept_prompt(with: 'Linus Torvalds') do\n  click_link('Show Prompt About Linux')\nend\nexpect(message).to eq('Who is the chief architect of Linux?')\n```\n\n### \u003ca name=\"debugging\"\u003e\u003c/a\u003eDebugging\n\nIt can be useful to take a snapshot of the page as it currently is and take a\nlook at it:\n\n```ruby\nsave_and_open_page\n```\n\nYou can also retrieve the current state of the DOM as a string using\n\u003ctt\u003e[page.html](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#html-instance_method)\u003c/tt\u003e.\n\n```ruby\nprint page.html\n```\n\nThis is mostly useful for debugging. You should avoid testing against the\ncontents of `page.html` and use the more expressive finder methods instead.\n\nFinally, in drivers that support it, you can save a screenshot:\n\n```ruby\npage.save_screenshot('screenshot.png')\n```\n\nOr have it save and automatically open:\n\n```ruby\nsave_and_open_screenshot\n```\n\nScreenshots are saved to `Capybara.save_path`, relative to the app directory.\nIf you have required `capybara/rails`, `Capybara.save_path` will default to\n`tmp/capybara`.\n\n## \u003ca name=\"selectors\"\u003e\u003c/a\u003eSelectors\n\nHelpers and matchers that accept Selectors share a common method signature that\nincludes:\n\n1. a positional Name argument\n2. a positional Locator argument\n3. keyword Filter arguments\n4. a predicate Filter block argument\n\nThese arguments are usually optional in one way or another.\n\n### \u003ca name=\"selectors-name\"\u003e\u003c/a\u003eName\n\nThe name argument determines the Selector to use. The argument is optional when\na helper explicitly conveys the selector name (for example, [`find_field`][]\nuses `:field`, [`find_link`][] uses `:link`, etc):\n\n```ruby\npage.html # =\u003e '\u003ca href=\"/\"\u003eHome\u003c/a\u003e'\n\npage.find(:link) == page.find_link\n\npage.html # =\u003e '\u003cinput\u003e'\n\npage.find(:field) == page.find_field\n```\n\n### \u003ca name=\"selectors-locator\"\u003e\u003c/a\u003eLocator\n\nThe locator argument usually represents information that can most meaningfully\ndistinguish an element that matches the selector from an element that does not:\n\n```ruby\npage.html # =\u003e '\u003cdiv id=\"greeting\"\u003eHello world\u003c/div\u003e'\n\npage.find(:css, 'div').text     # =\u003e 'Hello world'\npage.find(:xpath, './/div').text # =\u003e 'Hello world'\n```\n\nGeneral purpose finder methods like [`find`][] and [`all`][] can accept the\nlocator as their first positional argument when the method can infer the default\nvalue from the [`Capybara.default_selector`][] configuration:\n\n```ruby\npage.html # =\u003e '\u003cdiv id=\"greeting\"\u003eHello world\u003c/div\u003e'\n\nCapybara.default_selector = :css\n\npage.find('div').text     # =\u003e 'Hello world'\n\nCapybara.default_selector = :xpath\n\npage.find('.//div').text # =\u003e 'Hello world'\n```\n\nThe locator argument's semantics are context-specific, and depend on the\nselector. The types of arguments are varied. Some selectors support `String` or\n`Regexp` arguments, while others like `:table_row` support `Array\u003cString\u003e` and\n`Hash\u003cString, String\u003e`:\n\n```ruby\npage.html # =\u003e '\u003clabel for=\"greeting\"\u003eGreeting\u003c/label\u003e\n          #     \u003cinput id=\"greeting\" name=\"content\"\u003e'\n\n# find by the \u003cinput\u003e element's [id] attribute\npage.find(:id, 'greeting') == page.find_by_id('greeting') # =\u003e true\n\n# find by the \u003cinput\u003e element's [id] attribute\npage.find(:field, 'greeting') == page.find_field('greeting') # =\u003e true\n\n# find by the \u003cinput\u003e element's [name] attribute\npage.find(:field, 'content') == page.find_field('content') # =\u003e true\n\n# find by the \u003clabel\u003e element's text\npage.find(:field, 'Greeting') == page.find_field('Greeting') # =\u003e true\n\npage.html # =\u003e '\u003ctable\u003e\n          #       \u003ctr\u003e\n          #         \u003cth\u003eA\u003c/th\u003e\n          #         \u003cth\u003eB\u003c/th\u003e\n          #       \u003c/tr\u003e\n          #       \u003ctr\u003e\n          #         \u003ctd\u003e1\u003c/td\u003e\n          #         \u003ctd\u003e2\u003c/td\u003e\n          #       \u003c/tr\u003e\n          #     \u003c/table\u003e'\n\n# find by \u003ctd\u003e content\npage.find(:table_row, ['1', '2']) == page.find(:css, 'tr:last-of-type') # =\u003e true\n\n# find by \u003cth\u003e content paired with corresponding \u003ctd\u003e content\npage.find(:table_row, 'A' =\u003e '1') == page.find(:table_row, 'B' =\u003e '2') # =\u003e true\n```\n\n### \u003ca name=\"selectors-filters\"\u003e\u003c/a\u003e Filters\n\nAll filters are optional. The supported set of keys is a mixture of both global\nand context-specific filters.The supported types of values depend on the\ncontext:\n\n```ruby\npage.html # =\u003e '\u003ca href=\"/\"\u003eHome\u003c/a\u003e'\n\n# find by the [href] attribute\npage.find_link(href: '/') == page.find_link(text: 'Home') # =\u003e true\n\npage.html # =\u003e '\u003cdiv id=\"element\" data-attribute=\"value\"\u003eContent\u003c/div\u003e'\n\n# find by the [id] attribute\npage.find(id: 'element') == page.find(text: 'Content') # =\u003e true\n\n# find by the [data-attribute] attribute\npage.find(:element, 'data-attribute': /value/) == page.find(text: 'Content') # =\u003e true\n\npage.html # =\u003e '\u003cinput type=\"checkbox\"\u003e'\n\n# find by the absence of the [checked] attribute\npage.find_field(checked: false) == page.find_field(unchecked: true) # =\u003e true\n```\n\nThe predicate block is always optional. When there are results for a selector\nquery, the block is called with each item in the result set. When the block\nevaluates to true, the item is included from the result set. Otherwise, the item\nis excluded:\n\n```ruby\npage.html # =\u003e '\u003cinput role=\"switch\" type=\"checkbox\" checked\u003e'\n\nswitch = page.find_field { |input| input[\"role\"] == \"switch\" }\nfield = page.find_field(checked: true)\n\nswitch == field # =\u003e true\n```\n\n[`find`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find\n[`all`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:all\n[`Capybara.default_selector`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara%2Econfigure\n[`find_by_id`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find_by_id\n[`find_field`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find_field\n[`find_link`]: https://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders:find_link\n\n## \u003ca name=\"matching\"\u003e\u003c/a\u003eMatching\n\nIt is possible to customize how Capybara finds elements. At your disposal\nare two options, `Capybara.exact` and `Capybara.match`.\n\n### \u003ca name=\"exactness\"\u003e\u003c/a\u003eExactness\n\n`Capybara.exact` and the `exact` option work together with the `is` expression\ninside the XPath gem. When `exact` is true, all `is` expressions match exactly,\nwhen it is false, they allow substring matches. Many of the selectors built into\nCapybara use the `is` expression. This way you can specify whether you want to\nallow substring matches or not. `Capybara.exact` is false by default.\n\nFor example:\n\n```ruby\nclick_link(\"Password\") # also matches \"Password confirmation\"\nCapybara.exact = true\nclick_link(\"Password\") # does not match \"Password confirmation\"\nclick_link(\"Password\", exact: false) # can be overridden\n```\n\n### \u003ca name=\"strategy\"\u003e\u003c/a\u003eStrategy\n\nUsing `Capybara.match` and the equivalent `match` option, you can control how\nCapybara behaves when multiple elements all match a query. There are currently\nfour different strategies built into Capybara:\n\n1. **first:** Just picks the first element that matches.\n2. **one:** Raises an error if more than one element matches.\n3. **smart:** If `exact` is `true`, raises an error if more than one element\n   matches, just like `one`. If `exact` is `false`, it will first try to find\n   an exact match. An error is raised if more than one element is found. If no\n   element is found, a new search is performed which allows partial matches. If\n   that search returns multiple matches, an error is raised.\n4. **prefer_exact:** If multiple matches are found, some of which are exact,\n   and some of which are not, then the first exactly matching element is\n   returned.\n\nThe default for `Capybara.match` is `:smart`. To emulate the behaviour in\nCapybara 2.0.x, set `Capybara.match` to `:one`. To emulate the behaviour in\nCapybara 1.x, set `Capybara.match` to `:prefer_exact`.\n\n## \u003ca name=\"transactions-and-database-setup\"\u003e\u003c/a\u003eTransactions and database setup\n\n**Note:**  Rails 5.1+ \"safely\" shares the database connection between the app and test threads.  Therefore,\nif using Rails 5.1+ you SHOULD be able to ignore this section.\n\nSome Capybara drivers need to run against an actual HTTP server. Capybara takes\ncare of this and starts one for you in the same process as your test, but on\nanother thread. Selenium is one of those drivers, whereas RackTest is not.\n\nIf you are using a SQL database, it is common to run every test in a\ntransaction, which is rolled back at the end of the test, rspec-rails does this\nby default out of the box for example. Since transactions are usually not\nshared across threads, this will cause data you have put into the database in\nyour test code to be invisible to Capybara.\n\nCucumber handles this by using truncation instead of transactions, i.e. they\nempty out the entire database after each test. You can get the same behaviour\nby using a gem such as [database_cleaner](https://github.com/DatabaseCleaner/database_cleaner).\n\n## \u003ca name=\"asynchronous-javascript-ajax-and-friends\"\u003e\u003c/a\u003eAsynchronous JavaScript (Ajax and friends)\n\nWhen working with asynchronous JavaScript, you might come across situations\nwhere you are attempting to interact with an element which is not yet present\non the page. Capybara automatically deals with this by waiting for elements\nto appear on the page.\n\nWhen issuing instructions to the DSL such as:\n\n```ruby\nclick_link('foo')\nclick_link('bar')\nexpect(page).to have_content('baz')\n```\n\nIf clicking on the *foo* link triggers an asynchronous process, such as\nan Ajax request, which, when complete will add the *bar* link to the page,\nclicking on the *bar* link would be expected to fail, since that link doesn't\nexist yet. However, Capybara is smart enough to retry finding the link for a\nbrief period of time before giving up and throwing an error. The same is true of\nthe next line, which looks for the content *baz* on the page; it will retry\nlooking for that content for a brief time. You can adjust how long this period\nis (the default is 2 seconds):\n\n```ruby\nCapybara.default_max_wait_time = 5\n```\n\nBe aware that because of this behaviour, the following two statements are **not**\nequivalent, and you should **always** use the latter!\n\n```ruby\n# Given use of a driver where the page is loaded when visit returns\n# and that Capybara.predicates_wait is `true`\n# consider a page where the `a` tag is removed through AJAX after 1s\nvisit(some_path)\n!page.has_xpath?('a')  # is false\npage.has_no_xpath?('a')  # is true\n```\n\nFirst expression:\n- `has_xpath?('a')` is called right after `visit` returns. It is `true` because the link has not yet been removed\n- Capybara does not wait upon successful predicates/assertions, therefore **has_xpath? returns `true` immediately**\n- The expression returns `false` (because it is negated with the leading `!`)\n\nSecond expression:\n- `has_no_xpath?('a')` is called right after `visit` returns. It is `false` because the link has not yet been removed.\n- Capybara waits upon failed predicates/assertions, therefore **has_no_xpath? does not return `false` immediately**\n- Capybara will periodically re-check the predicate/assertion up to the `default_max_wait_time` defined\n- after 1s, the predicate becomes `true` (because the link has been removed)\n- The expression returns `true`\n\nCapybara's RSpec matchers, however, are smart enough to handle either form.\nThe two following statements are functionally equivalent:\n\n```ruby\nexpect(page).not_to have_xpath('a')\nexpect(page).to have_no_xpath('a')\n```\n\nCapybara's waiting behaviour is quite advanced, and can deal with situations\nsuch as the following line of code:\n\n```ruby\nexpect(find('#sidebar').find('h1')).to have_content('Something')\n```\n\nEven if JavaScript causes `#sidebar` to disappear off the page, Capybara\nwill automatically reload it and any elements it contains. So if an AJAX\nrequest causes the contents of `#sidebar` to change, which would update\nthe text of the `h1` to \"Something\", and this happened, this test would\npass. If you do not want this behaviour, you can set\n`Capybara.automatic_reload` to `false`.\n\n## \u003ca name=\"using-the-dsl-elsewhere\"\u003e\u003c/a\u003eUsing the DSL elsewhere\n\nYou can mix the DSL into any context by including \u003ctt\u003eCapybara::DSL\u003c/tt\u003e:\n\n\n```ruby\nrequire 'capybara/dsl'\n\nCapybara.default_driver = :webkit\n\nmodule MyModule\n  include Capybara::DSL\n\n  def login!\n    within(:xpath, \".//form[@id='session']\") do\n      fill_in 'Email', with: 'user@example.com'\n      fill_in 'Password', with: 'password'\n    end\n    click_button 'Sign in'\n  end\nend\n```\n\nThis enables its use in unsupported testing frameworks, and for general-purpose scripting.\n\n## \u003ca name=\"calling-remote-servers\"\u003e\u003c/a\u003eCalling remote servers\n\nNormally Capybara expects to be testing an in-process Rack application, but you\ncan also use it to talk to a web server running anywhere on the internet, by\nsetting app_host:\n\n```ruby\nCapybara.current_driver = :selenium\nCapybara.app_host = 'http://www.google.com'\n...\nvisit('/')\n```\n\n**Note**: the default driver (`:rack_test`) does not support running\nagainst a remote server. With drivers that support it, you can also visit any\nURL directly:\n\n```ruby\nvisit('http://www.google.com')\n```\n\nBy default Capybara will try to boot a rack application automatically. You\nmight want to switch off Capybara's rack server if you are running against a\nremote application:\n\n```ruby\nCapybara.run_server = false\n```\n\n## \u003ca name=\"using-sessions\"\u003e\u003c/a\u003eUsing sessions\n\nCapybara manages named sessions (:default if not specified) allowing multiple sessions using the same driver and test app instance to be interacted with.\nA 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.\n\n### Named sessions\nTo perform operations in a different session and then revert to the previous session\n\n```ruby\nCapybara.using_session(\"Bob's session\") do\n   #do something in Bob's browser session\nend\n #reverts to previous session\n```\n\nTo permanently switch the current session to a different session\n\n```ruby\nCapybara.session_name = \"some other session\"\n```\n\n### \u003ca name=\"using-sessions-manually\"\u003e\u003c/a\u003eUsing sessions manually\n\nFor ultimate control, you can instantiate and use a\n[Session](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session)\nmanually.\n\n```ruby\nrequire 'capybara'\n\nsession = Capybara::Session.new(:webkit, my_rack_app)\nsession.within(\"form#session\") do\n  session.fill_in 'Email', with: 'user@example.com'\n  session.fill_in 'Password', with: 'password'\nend\nsession.click_button 'Sign in'\n```\n\n## \u003ca name=\"xpath-css-and-selectors\"\u003e\u003c/a\u003eXPath, CSS and selectors\n\nCapybara does not try to guess what kind of selector you are going to give it,\nand will always use CSS by default.  If you want to use XPath, you'll need to\ndo:\n\n```ruby\nwithin(:xpath, './/ul/li') { ... }\nfind(:xpath, './/ul/li').text\nfind(:xpath, './/li[contains(.//a[@href = \"#\"]/text(), \"foo\")]').value\n```\n\nAlternatively you can set the default selector to XPath:\n\n```ruby\nCapybara.default_selector = :xpath\nfind('.//ul/li').text\n```\n\nCapybara provides a number of other built-in selector types. The full list, along\nwith applicable filters, can be seen at [built-in selectors](https://www.rubydoc.info/github/teamcapybara/capybara/Capybara/Selector)\n\nCapybara also allows you to add custom selectors, which can be very useful if you\nfind yourself using the same kinds of selectors very often. The examples below are very\nsimple, and there are many available features not demonstrated. For more in-depth examples\nplease see Capybaras built-in selector definitions.\n\n```ruby\nCapybara.add_selector(:my_attribute) do\n  xpath { |id| XPath.descendant[XPath.attr(:my_attribute) == id.to_s] }\nend\n\nCapybara.add_selector(:row) do\n  xpath { |num| \".//tbody/tr[#{num}]\" }\nend\n\nCapybara.add_selector(:flash_type) do\n  css { |type| \"#flash.#{type}\" }\nend\n```\n\nThe block given to xpath must always return an XPath expression as a String, or\nan XPath expression generated through the XPath gem. You can now use these\nselectors like this:\n\n```ruby\nfind(:my_attribute, 'post_123') # find element with matching attribute\nfind(:row, 3) # find 3rd row in table body\nfind(:flash_type, :notice) # find element with id of 'flash' and class of 'notice'\n```\n\n## \u003ca name=\"beware-the-xpath--trap\"\u003e\u003c/a\u003eBeware the XPath // trap\n\nIn XPath the expression // means something very specific, and it might not be what\nyou think. Contrary to common belief, // means \"anywhere in the document\" not \"anywhere\nin the current context\". As an example:\n\n```ruby\npage.find(:xpath, '//body').all(:xpath, '//script')\n```\n\nYou might expect this to find all script tags in the body, but actually, it finds all\nscript tags in the entire document, not only those in the body! What you're looking\nfor is the .// expression which means \"any descendant of the current node\":\n\n```ruby\npage.find(:xpath, '//body').all(:xpath, './/script')\n```\nThe same thing goes for within:\n\n```ruby\nwithin(:xpath, '//body') do\n  page.find(:xpath, './/script')\n  within(:xpath, './/table/tbody') do\n  ...\n  end\nend\n```\n\n## \u003ca name=\"configuring-and-adding-drivers\"\u003e\u003c/a\u003eConfiguring and adding drivers\n\nCapybara makes it convenient to switch between different drivers. It also exposes\nan API to tweak those drivers with whatever settings you want, or to add your own\ndrivers. This is how to override the selenium driver configuration to use chrome:\n\n```ruby\nCapybara.register_driver :selenium do |app|\n  Capybara::Selenium::Driver.new(app, :browser =\u003e :chrome)\nend\n```\n\nHowever, it's also possible to give this configuration a different name.\n\n```ruby\n# Note: Capybara registers this by default\nCapybara.register_driver :selenium_chrome do |app|\n  Capybara::Selenium::Driver.new(app, :browser =\u003e :chrome)\nend\n```\n\nThen tests can switch between using different browsers effortlessly:\n```ruby\nCapybara.current_driver = :selenium_chrome\n```\n\nWhatever is returned from the block should conform to the API described by\nCapybara::Driver::Base, it does not however have to inherit from this class.\nGems can use this API to add their own drivers to Capybara.\n\nThe [Selenium wiki](https://github.com/SeleniumHQ/selenium/wiki/Ruby-Bindings) has\nadditional info about how the underlying driver can be configured.\n\n## \u003ca name=\"gotchas\"\u003e\u003c/a\u003eGotchas:\n\n* Access to session and request is not possible from the test, Access to\n  response is limited. Some drivers allow access to response headers and HTTP\n  status code, but this kind of functionality is not provided by some drivers,\n  such as Selenium.\n\n* Access to Rails specific stuff (such as `controller`) is unavailable,\n  since we're not using Rails' integration testing.\n\n* Freezing time: It's common practice to mock out the Time so that features\n  that depend on the current Date work as expected. This can be problematic on\n  ruby/platform combinations that don't support access to a monotonic process clock,\n  since Capybara's Ajax timing uses the system time, resulting in Capybara\n  never timing out and just hanging when a failure occurs. It's still possible to\n  use gems which allow you to travel in time, rather than freeze time.\n  One such gem is [Timecop](https://github.com/travisjeffery/timecop).\n\n* When using Rack::Test, beware if attempting to visit absolute URLs. For\n  example, a session might not be shared between visits to `posts_path`\n  and `posts_url`. If testing an absolute URL in an Action Mailer email,\n  set `default_url_options` to match the Rails default of\n  `www.example.com`.\n\n* Server errors will only be raised in the session that initiates the server thread. If you\n  are testing for specific server errors and using multiple sessions make sure to test for the\n  errors using the initial session (usually :default)\n\n* If WebMock is enabled, you may encounter a \"Too many open files\"\n  error. A simple `page.find` call may cause thousands of HTTP requests\n  until the timeout occurs. By default, WebMock will cause each of these\n  requests to spawn a new connection. To work around this problem, you\n  may need to [enable WebMock's `net_http_connect_on_start: true`\n  parameter](https://github.com/bblimke/webmock/blob/master/README.md#connecting-on-nethttpstart).\n\n## \u003ca name=\"threadsafe\"\u003e\u003c/a\u003e\"Threadsafe\" mode\n\nIn normal mode most of Capybara's configuration options are global settings which can cause issues\nif using multiple sessions and wanting to change a setting for only one of the sessions.  To provide\nsupport for this type of usage Capybara now provides a \"threadsafe\" mode which can be enabled by setting\n\n```ruby\nCapybara.threadsafe = true\n```\n\nThis setting can only be changed before any sessions have been created.  In \"threadsafe\" mode the following\nbehaviors of Capybara change\n\n* Most options can now be set on a session.  These can either be set at session creation time or after, and\n  default to the global options at the time of session creation.  Options which are NOT session specific are\n  `app`, `reuse_server`, `default_driver`, `javascript_driver`, and (obviously) `threadsafe`.  Any drivers and servers\n  registered through `register_driver` and `register_server` are also global.\n\n  ```ruby\n  my_session = Capybara::Session.new(:driver, some_app) do |config|\n    config.automatic_label_click = true # only set for my_session\n  end\n  my_session.config.default_max_wait_time = 10 # only set for my_session\n  Capybara.default_max_wait_time = 2 # will not change the default_max_wait in my_session\n  ```\n\n* `current_driver` and `session_name` are thread specific.  This means that `using_session` and\n  `using_driver` also only affect the current thread.\n\n## \u003ca name=\"development\"\u003e\u003c/a\u003eDevelopment\n\nTo set up a development environment, simply do:\n\n```bash\nbundle install\nbundle exec rake  # run the test suite with Firefox - requires `geckodriver` to be installed\nbundle exec rake spec_chrome # run the test suite with Chrome - require `chromedriver` to be installed\n```\n\nSee\n[CONTRIBUTING.md](https://github.com/teamcapybara/capybara/blob/master/CONTRIBUTING.md)\nfor how to send issues and pull requests.\n","funding_links":["https://www.patreon.com/capybara"],"categories":["Testing","测试","Gems","Ruby"],"sub_categories":["Omniauth","Browser testing","Testing"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjnicklas%2Fcapybara","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjnicklas%2Fcapybara","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjnicklas%2Fcapybara/lists"}