capybara 2.5.0 → 2.18.0

data/README.md

@@ -1,14 +1,21 @@
 # Capybara
 
-[![Build Status](https://secure.travis-ci.org/jnicklas/capybara.png)](http://travis-ci.org/jnicklas/capybara)
-[![Dependency Status](https://gemnasium.com/jnicklas/capybara.png)](https://gemnasium.com/jnicklas/capybara)
-[![Code Climate](https://codeclimate.com/github/jnicklas/capybara.png)](https://codeclimate.com/github/jnicklas/capybara)
+[![Build Status](https://secure.travis-ci.org/teamcapybara/capybara.svg)](https://travis-ci.org/teamcapybara/capybara)
+[![Dependency Status](https://gemnasium.com/teamcapybara/capybara.svg)](https://gemnasium.com/teamcapybara/capybara)
+[![Code Climate](https://codeclimate.com/github/teamcapybara/capybara.svg)](https://codeclimate.com/github/teamcapybara/capybara)
+[![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)
 
 Capybara helps you test web applications by simulating how a real user would
 interact with your app. It is agnostic about the driver running your tests and
 comes with Rack::Test and Selenium support built in. WebKit is supported
 through an external gem.
 
+## Support Capybara
+
+If you and/or your company find value in Capybara and would like to contribute financially to its ongoing maintenance and development, please visit
+<a href="https://www.patreon.com/capybara">Patreon</a>
+
+
 **Need help?** Ask on the mailing list (please do not open an issue on
 GitHub): http://groups.google.com/group/ruby-capybara
 
@@ -19,7 +26,8 @@ GitHub): http://groups.google.com/group/ruby-capybara
 - [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)
-- [Using Capybara with MiniTest::Spec](#using-capybara-with-minitestspec)
+- [Using Capybara with Minitest](#using-capybara-with-minitest)
+- [Using Capybara with Minitest::Spec](#using-capybara-with-minitestspec)
 - [Drivers](#drivers)
     - [Selecting the Driver](#selecting-the-driver)
     - [RackTest](#racktest)
@@ -44,14 +52,15 @@ GitHub): http://groups.google.com/group/ruby-capybara
 - [Asynchronous JavaScript (Ajax and friends)](#asynchronous-javascript-ajax-and-friends)
 - [Using the DSL elsewhere](#using-the-dsl-elsewhere)
 - [Calling remote servers](#calling-remote-servers)
-- [Using the sessions manually](#using-the-sessions-manually)
+- [Using sessions](#using-sessions)
 - [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)
+- ["Threadsafe" mode](#threadsafe)
 - [Development](#development)
 
-## Key benefits
+## <a name="key-benefits"></a>Key benefits
 
 - **No setup** necessary for Rails and Rack application. Works out of the box.
 - **Intuitive API** which mimics the language an actual user would use.
@@ -60,7 +69,7 @@ GitHub): http://groups.google.com/group/ruby-capybara
 - **Powerful synchronization** features mean you never have to manually wait
   for asynchronous processes to complete.
 
-## Setup
+## <a name="setup"></a>Setup
 
 Capybara requires Ruby 1.9.3 or later. To install, add this line to your
 `Gemfile` and run `bundle install`:
@@ -69,6 +78,8 @@ Capybara requires Ruby 1.9.3 or later. To install, add this line to your
 gem 'capybara'
 ```
 
+**Note:** If using Ruby < 2.0 you will also need to limit the version of rack to < 2.0
+
 If the application that you are testing is a Rails app, add this line to your test helper file:
 
 ```ruby
@@ -85,9 +96,15 @@ Capybara.app = MyRackApp
 ```
 
 If you need to test JavaScript, or if your app interacts with (or is located at)
-a remote URL, you'll need to [use a different driver](#drivers).
+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.
 
-## Using Capybara with Cucumber
+```ruby
+Capybara.server = :puma # Until your setup is working
+Capybara.server = :puma, { Silent: true } # To clean up your test output
+```
+
+## <a name="using-capybara-with-cucumber"></a>Using Capybara with Cucumber
 
 The `cucumber-rails` gem comes with Capybara support built-in. If you
 are not using Rails, manually load the `capybara/cucumber` module:
@@ -102,8 +119,8 @@ You can use the Capybara DSL in your steps, like so:
 ```ruby
 When /I sign in/ do
   within("#session") do
-    fill_in 'Email', :with => 'user@example.com'
-    fill_in 'Password', :with => 'password'
+    fill_in 'Email', with: 'user@example.com'
+    fill_in 'Password', with: 'password'
   end
   click_button 'Sign in'
 end
@@ -119,19 +136,22 @@ Scenario: do something Ajaxy
   ...
 ```
 
-There are also explicit `@selenium` and `@rack_test`
-tags set up for you.
+There are also explicit tags for each registered driver set up for you (`@selenium`, `@rack_test`, etc).
 
-## Using Capybara with RSpec
+## <a name="using-capybara-with-rspec"></a>Using Capybara with RSpec
 
-Load RSpec 2.x support by adding the following line (typically to your
+Load RSpec 2+ support by adding the following line (typically to your
 `spec_helper.rb` file):
 
 ```ruby
 require 'capybara/rspec'
 ```
 
-If you are using Rails, put your Capybara specs in `spec/features`.
+If you are using Rails, put your Capybara specs in `spec/features` (only works
+if [you have it configured in
+RSpec](https://www.relishapp.com/rspec/rspec-rails/docs/upgrade#file-type-inference-disabled))
+and if you have your Capybara specs in a different directory, then tag the
+example groups with `:type => :feature`.
 
 If you are not using Rails, tag all the example groups in which you want to use
 Capybara with `:type => :feature`.
@@ -141,14 +161,14 @@ You can now write your specs like so:
 ```ruby
 describe "the signin process", :type => :feature do
   before :each do
-    User.make(:email => 'user@example.com', :password => 'password')
+    User.make(email: 'user@example.com', password: 'password')
   end
 
   it "signs me in" do
     visit '/sessions/new'
     within("#session") do
-      fill_in 'Email', :with => 'user@example.com'
-      fill_in 'Password', :with => 'password'
+      fill_in 'Email', with: 'user@example.com'
+      fill_in 'Password', with: 'password'
     end
     click_button 'Sign in'
     expect(page).to have_content 'Success'
@@ -156,12 +176,12 @@ describe "the signin process", :type => :feature do
 end
 ```
 
-Use `:js => true` to switch to the `Capybara.javascript_driver`
+Use `js: true` to switch to the `Capybara.javascript_driver`
 (`:selenium` by default), or provide a `:driver` option to switch
 to one specific driver. For example:
 
 ```ruby
-describe 'some stuff which requires js', :js => true do
+describe 'some stuff which requires js', js: true do
   it 'will use the default js driver'
   it 'will switch to one specific driver', :driver => :webkit
 end
@@ -172,26 +192,26 @@ Capybara also comes with a built in DSL for creating descriptive acceptance test
 ```ruby
 feature "Signing in" do
   background do
-    User.make(:email => 'user@example.com', :password => 'caplin')
+    User.make(email: 'user@example.com', password: 'caplin')
   end
 
   scenario "Signing in with correct credentials" do
     visit '/sessions/new'
     within("#session") do
-      fill_in 'Email', :with => 'user@example.com'
-      fill_in 'Password', :with => 'caplin'
+      fill_in 'Email', with: 'user@example.com'
+      fill_in 'Password', with: 'caplin'
     end
     click_button 'Sign in'
     expect(page).to have_content 'Success'
   end
 
-  given(:other_user) { User.make(:email => 'other@example.com', :password => 'rous') }
+  given(:other_user) { User.make(email: 'other@example.com', password: 'rous') }
 
   scenario "Signing in as another user" do
     visit '/sessions/new'
     within("#session") do
-      fill_in 'Email', :with => other_user.email
-      fill_in 'Password', :with => other_user.password
+      fill_in 'Email', with: other_user.email
+      fill_in 'Password', with: other_user.password
     end
     click_button 'Sign in'
     expect(page).to have_content 'Invalid email or password'
@@ -217,16 +237,49 @@ RSpec.describe "todos/show.html.erb", type: :view do
 end
 ```
 
-## Using Capybara with Test::Unit
+**Note: When you require 'capybara/rspec' proxy methods are installed to work around name collisions between Capybara::DSL methods
+  `all`/`within` and the identically named built-in RSpec matchers. If you opt not to require 'capybara/rspec' you can install the proxy methods by requiring 'capybara/rspec/matcher_proxies' after requiring RSpec and 'capybara/dsl'**
+
+## <a name="using-capybara-with-testunit"></a>Using Capybara with Test::Unit
+
+* 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
 
 * If you are using Rails, add the following code in your `test_helper.rb`
     file to make Capybara available in all test cases deriving from
     `ActionDispatch::IntegrationTest`:
 
     ```ruby
+    require 'capybara/rails'
+    require 'capybara/minitest'
+
     class ActionDispatch::IntegrationTest
       # Make the Capybara DSL available in all integration tests
       include Capybara::DSL
+      # Make `assert_*` methods behave like Minitest assertions
+      include Capybara::Minitest::Assertions
+
+      # Reset sessions and driver between tests
+      # Use super wherever this method is redefined in your individual test classes
+      def teardown
+        Capybara.reset_sessions!
+        Capybara.use_default_driver
+      end
     end
     ```
 
@@ -234,8 +287,11 @@ end
   so:
 
     ```ruby
-    class CapybaraTestCase < Test::Unit::TestCase
+    require 'capybara/minitest'
+
+    class CapybaraTestCase < Minitest::Test
       include Capybara::DSL
+      include Capybara::Minitest::Assertions
 
       def teardown
         Capybara.reset_sessions!
@@ -261,24 +317,19 @@ class BlogTest < ActionDispatch::IntegrationTest
 end
 ```
 
-## Using Capybara with MiniTest::Spec
+## <a name="using-capybara-with-minitestspec"></a>Using Capybara with Minitest::Spec
 
-Set up your base class as with Test::Unit. (On Rails, the right base class
-could be something other than ActionDispatch::IntegrationTest.)
-
-The capybara_minitest_spec gem ([GitHub](https://github.com/ordinaryzelig/capybara_minitest_spec),
-[rubygems.org](https://rubygems.org/gems/capybara_minitest_spec)) provides MiniTest::Spec
-expectations for Capybara. For example:
+Follow the above instructions for Minitest and additionally require capybara/minitest/spec
 
 ```ruby
 page.must_have_content('Important!')
 ```
 
-## Drivers
+## <a name="drivers"></a>Drivers
 
 Capybara uses the same DSL to drive a variety of browser and headless drivers.
 
-### Selecting the Driver
+### <a name="selecting-the-driver"></a>Selecting the Driver
 
 By default, Capybara uses the `:rack_test` driver, which is fast but limited: it
 does not support JavaScript, nor is it able to access HTTP resources outside of
@@ -287,12 +338,12 @@ 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:
 
 ```ruby
-Capybara.default_driver = :selenium
+Capybara.default_driver = :selenium # :selenium_chrome and :selenium_chrome_headless are also registered
 ```
 
 However, if you are using RSpec or Cucumber, 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
+tests that require a JavaScript-capable driver using `js: true` or
 `@javascript`, respectively.  By default, JavaScript tests are run using the
 `:selenium` driver. You can change this by setting
 `Capybara.javascript_driver`.
@@ -309,7 +360,7 @@ Capybara.use_default_driver       # switch back to default driver
 **Note**: switching the driver creates a new session, so you may not be able to
 switch in the middle of a test.
 
-### RackTest
+### <a name="racktest"></a>RackTest
 
 RackTest is Capybara's default driver. It is written in pure Ruby and does not
 have any support for executing JavaScript. Since the RackTest driver interacts
@@ -328,15 +379,15 @@ RackTest can be configured with a set of headers like this:
 
 ```ruby
 Capybara.register_driver :rack_test do |app|
-  Capybara::RackTest::Driver.new(app, :headers => { 'HTTP_USER_AGENT' => 'Capybara' })
+  Capybara::RackTest::Driver.new(app, headers: { 'HTTP_USER_AGENT' => 'Capybara' })
 end
 ```
 
 See the section on adding and configuring drivers.
 
-### Selenium
+### <a name="selenium"></a>Selenium
 
-At the moment, Capybara supports [Selenium 2.0
+At the moment, Capybara supports [Selenium 2.0+
 (Webdriver)](http://seleniumhq.org/docs/01_introducing_selenium.html#selenium-2-aka-selenium-webdriver),
 *not* Selenium RC. In order to use Selenium, you'll need to install the
 `selenium-webdriver` gem, and add it to your Gemfile if you're using bundler.
@@ -347,7 +398,7 @@ able to start using Selenium right away.
 same transaction as your tests, causing data not to be shared between your test
 and test server, see "Transactions and database setup" below.
 
-### Capybara-webkit
+### <a name="capybara-webkit"></a>Capybara-webkit
 
 The [capybara-webkit driver](https://github.com/thoughtbot/capybara-webkit) is for true headless
 testing. It uses QtWebKit to start a rendering engine process. It can execute JavaScript as well.
@@ -365,18 +416,18 @@ And you can use it by:
 Capybara.javascript_driver = :webkit
 ```
 
-### Poltergeist
+### <a name="poltergeist"></a>Poltergeist
 
-[Poltergeist](https://github.com/jonleighton/poltergeist) is another
+[Poltergeist](https://github.com/teampoltergeist/poltergeist) is another
 headless driver which integrates Capybara with
 [PhantomJS](http://phantomjs.org/). It is truly headless, so doesn't
 require Xvfb to run on your CI server. It will also detect and report
 any Javascript errors that happen within the page.
 
-## The DSL
+## <a name="the-dsl"></a>The DSL
 
 *A complete reference is available at
-[rubydoc.info](http://rubydoc.info/github/jnicklas/capybara/master)*.
+[rubydoc.info](http://rubydoc.info/github/teamcapybara/capybara/master)*.
 
 **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.**
@@ -384,10 +435,10 @@ any Javascript errors that happen within the page.
 **Note**: All searches in Capybara are *case sensitive*. This is because
 Capybara heavily uses XPath, which doesn't support case insensitivity.
 
-### Navigating
+### <a name="navigating"></a>Navigating
 
 You can use the
-<tt>[visit](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#visit-instance_method)</tt>
+<tt>[visit](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#visit-instance_method)</tt>
 method to navigate to other pages:
 
 ```ruby
@@ -398,16 +449,21 @@ visit(post_comments_path(post))
 The visit method only takes a single parameter, the request method is **always**
 GET.
 
-You can get the [current path](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#current_path-instance_method)
-of the browsing session for test assertions:
+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:
 
 ```ruby
-expect(current_path).to eq(post_comments_path(post))
+expect(page).to have_current_path(post_comments_path(post))
 ```
 
-### Clicking links and buttons
+**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.
+
+### <a name="clicking-links-and-buttons"></a>Clicking links and buttons
 
-*Full reference: [Capybara::Node::Actions](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions)*
+*Full reference: [Capybara::Node::Actions](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Actions)*
 
 You can interact with the webapp by following links and buttons. Capybara
 automatically follows any redirects, and submits forms associated with buttons.
@@ -420,35 +476,35 @@ click_on('Link Text') # clicks on either links or buttons
 click_on('Button Value')
 ```
 
-### Interacting with forms
+### <a name="interacting-with-forms"></a>Interacting with forms
 
-*Full reference: [Capybara::Node::Actions](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions)*
+*Full reference: [Capybara::Node::Actions](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Actions)*
 
 There are a number of tools for interacting with form elements:
 
 ```ruby
-fill_in('First Name', :with => 'John')
-fill_in('Password', :with => 'Seekrit')
-fill_in('Description', :with => 'Really Long Text...')
+fill_in('First Name', with: 'John')
+fill_in('Password', with: 'Seekrit')
+fill_in('Description', with: 'Really Long Text...')
 choose('A Radio Button')
 check('A Checkbox')
 uncheck('A Checkbox')
 attach_file('Image', '/path/to/image.jpg')
-select('Option', :from => 'Select Box')
+select('Option', from: 'Select Box')
 ```
 
-### Querying
+### <a name="querying"></a>Querying
 
-*Full reference: [Capybara::Node::Matchers](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Matchers)*
+*Full reference: [Capybara::Node::Matchers](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Matchers)*
 
 Capybara has a rich set of options for querying the page for the existence of
 certain elements, and working with and manipulating those elements.
 
 ```ruby
 page.has_selector?('table tr')
-page.has_selector?(:xpath, '//table/tr')
+page.has_selector?(:xpath, './/table/tr')
 
-page.has_xpath?('//table/tr')
+page.has_xpath?('.//table/tr')
 page.has_css?('table tr.foo')
 page.has_content?('foo')
 ```
@@ -460,29 +516,41 @@ You can use these with RSpec's magic matchers:
 
 ```ruby
 expect(page).to have_selector('table tr')
-expect(page).to have_selector(:xpath, '//table/tr')
+expect(page).to have_selector(:xpath, './/table/tr')
 
-expect(page).to have_xpath('//table/tr')
+expect(page).to have_xpath('.//table/tr')
 expect(page).to have_css('table tr.foo')
 expect(page).to have_content('foo')
 ```
 
-### Finding
+### <a name="finding"></a>Finding
 
-_Full reference: [Capybara::Node::Finders](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Finders)_
+_Full reference: [Capybara::Node::Finders](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Node/Finders)_
 
 You can also find specific elements, in order to manipulate them:
 
 ```ruby
 find_field('First Name').value
+find_field(id: 'my_field').value
 find_link('Hello', :visible => :all).visible?
+find_link(class: ['some_class', 'some_other_class'], :visible => :all).visible?
+
 find_button('Send').click
+find_button(value: '1234').click
 
-find(:xpath, "//table/tr").click
+find(:xpath, ".//table/tr").click
 find("#overlay").find("h1").click
 all('a').each { |a| a[:href] }
 ```
 
+If you need to find elements by additional attributes/properties you can also pass a filter block, which will be checked inside the normal waiting behavior.
+If you find yourself needing to use this a lot you may be better off adding a [custom selector](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).
+
+```ruby
+find_field('First Name'){ |el| el['data-xyz'] == '123' }
+find("#img_loading"){ |img| img['complete'] == true }
+```
+
 **Note**: `find` will wait for an element to appear on the page, as explained in the
 Ajax section. If the element does not appear it will raise an error.
 
@@ -494,21 +562,21 @@ find('#navigation').click_link('Home')
 expect(find('#navigation')).to have_button('Sign out')
 ```
 
-### Scoping
+### <a name="scoping"></a>Scoping
 
 Capybara makes it possible to restrict certain actions, such as interacting with
 forms or clicking links and buttons, to within a specific area of the page. For
 this purpose you can use the generic
-<tt>[within](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#within-instance_method)</tt>
+<tt>[within](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#within-instance_method)</tt>
 method. Optionally you can specify which kind of selector to use.
 
 ```ruby
 within("li#employee") do
-  fill_in 'Name', :with => 'Jimmy'
+  fill_in 'Name', with: 'Jimmy'
 end
 
-within(:xpath, "//li[@id='employee']") do
-  fill_in 'Name', :with => 'Jimmy'
+within(:xpath, ".//li[@id='employee']") do
+  fill_in 'Name', with: 'Jimmy'
 end
 ```
 
@@ -518,15 +586,15 @@ specific table, identified by either id or text of the table's caption tag.
 
 ```ruby
 within_fieldset('Employee') do
-  fill_in 'Name', :with => 'Jimmy'
+  fill_in 'Name', with: 'Jimmy'
 end
 
 within_table('Employee') do
-  fill_in 'Name', :with => 'Jimmy'
+  fill_in 'Name', with: 'Jimmy'
 end
 ```
 
-### Working with windows
+### <a name="working-with-windows"></a>Working with windows
 
 Capybara provides some methods to ease finding and switching windows:
 
@@ -541,7 +609,7 @@ within_window facebook_window do
 end
 ```
 
-### Scripting
+### <a name="scripting"></a>Scripting
 
 In drivers which support it, you can easily execute JavaScript:
 
@@ -556,7 +624,7 @@ that this may break with more complicated expressions:
 result = page.evaluate_script('4 + 4');
 ```
 
-### Modals
+### <a name="modals"></a>Modals
 
 In drivers which support it, you can accept, dismiss and respond to alerts, confirms and prompts.
 
@@ -594,7 +662,7 @@ end
 expect(message).to eq('Who is the chief architect of Linux?')
 ```
 
-### Debugging
+### <a name="debugging"></a>Debugging
 
 It can be useful to take a snapshot of the page as it currently is and take a
 look at it:
@@ -604,7 +672,7 @@ save_and_open_page
 ```
 
 You can also retrieve the current state of the DOM as a string using
-<tt>[page.html](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#html-instance_method)</tt>.
+<tt>[page.html](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session#html-instance_method)</tt>.
 
 ```ruby
 print page.html
@@ -625,12 +693,16 @@ Or have it save and automatically open:
 save_and_open_screenshot
 ```
 
-## Matching
+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`.
+
+## <a name="matching"></a>Matching
 
 It is possible to customize how Capybara finds elements. At your disposal
 are two options, `Capybara.exact` and `Capybara.match`.
 
-### Exactness
+### <a name="exactness"></a>Exactness
 
 `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,
@@ -647,7 +719,7 @@ click_link("Password") # does not match "Password confirmation"
 click_link("Password", exact: false) # can be overridden
 ```
 
-### Strategy
+### <a name="strategy"></a>Strategy
 
 Using `Capybara.match` and the equivalent `match` option, you can control how
 Capybara behaves when multiple elements all match a query. There are currently
@@ -668,7 +740,10 @@ 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`.
 
-## Transactions and database setup
+## <a name="transactions-and-database-setup"></a>Transactions and database setup
+
+**Note:**  Rails 5.1+ now "safely" shares the database connection between the app and test threads.  Therefore,
+if using Rails 5.1+ you SHOULD be able to ignore this section.
 
 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
@@ -682,26 +757,9 @@ 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
-by using a gem such as [database_cleaner](https://github.com/bmabey/database_cleaner).
+by using a gem such as [database_cleaner](https://github.com/DatabaseCleaner/database_cleaner).
 
-It is also possible to force your ORM to use the same transaction for all
-threads.  This may have thread safety implications and could cause strange
-failures, so use caution with this approach. It can be implemented in
-ActiveRecord through the following monkey patch:
-
-```ruby
-class ActiveRecord::Base
-  mattr_accessor :shared_connection
-  @@shared_connection = nil
-
-  def self.connection
-    @@shared_connection || retrieve_connection
-  end
-end
-ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
-```
-
-## Asynchronous JavaScript (Ajax and friends)
+## <a name="asynchronous-javascript-ajax-and-friends"></a>Asynchronous JavaScript (Ajax and friends)
 
 When working with asynchronous JavaScript, you might come across situations
 where you are attempting to interact with an element which is not yet present
@@ -741,7 +799,7 @@ 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.
 
-Capybara's Rspec matchers, however, are smart enough to handle either form.
+Capybara's RSpec matchers, however, are smart enough to handle either form.
 The two following statements are functionally equivalent:
 
 ```ruby
@@ -763,13 +821,12 @@ the text of the `h1` to "Something", and this happened, this test would
 pass. If you do not want this behaviour, you can set
 `Capybara.automatic_reload` to `false`.
 
-## Using the DSL elsewhere
+## <a name="using-the-dsl-elsewhere"></a>Using the DSL elsewhere
 
 You can mix the DSL into any context by including <tt>Capybara::DSL</tt>:
 
 
 ```ruby
-require 'capybara'
 require 'capybara/dsl'
 
 Capybara.default_driver = :webkit
@@ -778,9 +835,9 @@ module MyModule
   include Capybara::DSL
 
   def login!
-    within("//form[@id='session']") do
-      fill_in 'Email', :with => 'user@example.com'
-      fill_in 'Password', :with => 'password'
+    within(:xpath, ".//form[@id='session']") do
+      fill_in 'Email', with: 'user@example.com'
+      fill_in 'Password', with: 'password'
     end
     click_button 'Sign in'
   end
@@ -789,7 +846,7 @@ end
 
 This enables its use in unsupported testing frameworks, and for general-purpose scripting.
 
-## Calling remote servers
+## <a name="calling-remote-servers"></a>Calling remote servers
 
 Normally Capybara expects to be testing an in-process Rack application, but you
 can also use it to talk to a web server running anywhere on the internet, by
@@ -818,40 +875,61 @@ remote application:
 Capybara.run_server = false
 ```
 
-## Using the sessions manually
+## <a name="using-sessions"></a>Using sessions
+
+Capybara manages named sessions (:default if not specified) allowing multiple sessions using the same driver and test app instance to be interacted with.
+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.
+
+### Named sessions
+To perform operations in a different session and then revert to the previous session
+
+```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"
+```
+
+### <a name="using-sessions-manually"></a>Using sessions manually
 
 For ultimate control, you can instantiate and use a
-[Session](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session)
+[Session](http://rubydoc.info/github/teamcapybara/capybara/master/Capybara/Session)
 manually.
 
 ```ruby
 require 'capybara'
 
 session = Capybara::Session.new(:webkit, my_rack_app)
-session.within("//form[@id='session']") do
-  session.fill_in 'Email', :with => 'user@example.com'
-  session.fill_in 'Password', :with => 'password'
+session.within("form#session") do
+  session.fill_in 'Email', with: 'user@example.com'
+  session.fill_in 'Password', with: 'password'
 end
 session.click_button 'Sign in'
 ```
 
-## XPath, CSS and selectors
+## <a name="xpath-css-and-selectors"></a>XPath, CSS and selectors
 
 Capybara does not try to guess what kind of selector you are going to give it,
 and will always use CSS by default.  If you want to use XPath, you'll need to
 do:
 
 ```ruby
-within(:xpath, '//ul/li') { ... }
-find(:xpath, '//ul/li').text
-find(:xpath, '//li[contains(.//a[@href = "#"]/text(), "foo")]').value
+within(:xpath, './/ul/li') { ... }
+find(:xpath, './/ul/li').text
+find(:xpath, './/li[contains(.//a[@href = "#"]/text(), "foo")]').value
 ```
 
 Alternatively you can set the default selector to XPath:
 
 ```ruby
 Capybara.default_selector = :xpath
-find('//ul/li').text
+find('.//ul/li').text
 ```
 
 Capybara allows you to add custom selectors, which can be very useful if you
@@ -881,7 +959,7 @@ find(:row, 3)
 find(:flash_type, :notice)
 ```
 
-## Beware the XPath // trap
+## <a name="beware-the-xpath--trap"></a>Beware the XPath // trap
 
 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
@@ -909,7 +987,7 @@ within(:xpath, '//body') do
 end
 ```
 
-## Configuring and adding drivers
+## <a name="configuring-and-adding-drivers"></a>Configuring and adding drivers
 
 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
@@ -938,10 +1016,10 @@ 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.
 
-The [Selenium wiki](http://code.google.com/p/selenium/wiki/RubyBindings) has
+The [Selenium wiki](https://github.com/SeleniumHQ/selenium/wiki/Ruby-Bindings) has
 additional info about how the underlying driver can be configured.
 
-## Gotchas:
+## <a name="gotchas"></a>Gotchas:
 
 * 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
@@ -957,7 +1035,7 @@ additional info about how the underlying driver can be configured.
   since Capybara's Ajax timing uses the system time, resulting in Capybara
   never timing out and just hanging when a failure occurs. It's still possible to
   use gems which allow you to travel in time, rather than freeze time.
-  One such gem is [Timecop](http://github.com/travisjeffery/timecop).
+  One such gem is [Timecop](https://github.com/travisjeffery/timecop).
 
 * When using Rack::Test, beware if attempting to visit absolute URLs. For
   example, a session might not be shared between visits to `posts_path`
@@ -969,7 +1047,36 @@ additional info about how the underlying driver can be configured.
   are testing for specific server errors and using multiple sessions make sure to test for the
   errors using the initial session (usually :default)
 
-## Development
+## <a name="threadsafe"></a>"Threadsafe" mode - BETA - may change
+
+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
+
+```ruby
+Capybara.threadsafe = true
+```
+
+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.
+
+  ```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
+  ```
+
+* `current_driver` and `session_name` are thread specific.  This means that `using_session` and
+  `using_driver` also only affect the current thread.
+
+## <a name="development"></a>Development
 
 To set up a development environment, simply do:
 
@@ -979,5 +1086,5 @@ bundle exec rake  # run the test suite
 ```
 
 See
-[CONTRIBUTING.md](https://github.com/jnicklas/capybara/blob/master/CONTRIBUTING.md)
+[CONTRIBUTING.md](https://github.com/teamcapybara/capybara/blob/master/CONTRIBUTING.md)
 for how to send issues and pull requests.