capybara 0.4.1.2 → 1.0.0.beta1

data/History.txt

@@ -1,3 +1,49 @@
+# Version 1.0.0
+
+Release date:
+
+### Added
+
+* Added DSL for acceptance tests, inspired by Luismi Cavallé's Steak [Luismi Cavalle and Jonas Nicklas]
+* Selenium driver automatically waits for AJAX requests to finish [mgiambalvo, Nicklas Ramhöj and Jonas Nicklas]
+* Support for switching between multiple named sessions [Tristan Dunn]
+* failure_message can be specified for Selectors [Jonas Nicklas]
+* RSpec matchers [David Chelimsky and Jonas Nicklas]
+* Added save_page to save tempfile without opening in browser [Jeff Kreeftmeijer]
+* Cucumber now switches automatically to a registered driver if the tag matches the name [Jonas Nicklas]
+* Added Session#text [Jonas Nicklas and Scott Cytacki]
+* Added Session#html as an alias for Session#body [Jo Liss]
+* Added Session#current_host method [Jonas Nicklas]
+* Buttons can now be clicked by title [Javier Martin]
+* :headers option for RackTest driver to set custom HTTP headers [Jonas Nicklas]
+
+### Removed
+
+* Culerity and Celerity drivers have been removed and split into separate gems [Gabriel Sobrinho]
+
+### Deprecated
+
+* `include Capybara` has been deprecated in favour of `include Capybara::DSL` [Jonas Nicklas]
+
+### Changed
+
+* Rack test driver class has been renamed from Capybara::Driver::RackTest to Capybara::RackTest::Driver [Jonas Nicklas]
+* Selenium driver class has been renamed from Capybara::Driver::Selenium to Capybara::Selenium::Driver [Jonas Nicklas]
+* Capybara now prefers visible elements over hidden elements, disable by setting Capybara.prefer_visible_elements = false [Jonas Nicklas and Nicklas Ramhöj]
+* For RSpec, :type => :request is now supported (and preferred over :acceptance) [Jo Liss]
+* Selenium driver tried to wait for AJAX requests to finish before proceeding [Jonas Nicklas and Nicklas Ramhöj]
+* Session no longer uses method missing, uses explicit delegates instead [Jonas Nicklas]
+
+### Fixed
+
+* The Rack::Test driver now respects maxlength on text fields [Guilherme Carvalho]
+* Allow for more than one save_and_open_page call per second [Jo Liss]
+* Automatically convert options to :count, :minimum, :maximum, etc. to integers [Keith Marcum]
+* Rack::Test driver honours maxlength on input fields [Guilherme Carvalho]
+* Rack::Test now works as expected with domains and subdomains [Jonas Nicklas]
+* Session is reset more thoroughly between tests. [Jonas Nicklas]
+* Raise error when uploading non-existant file [Jonas Nicklas]
+
 # Version 0.4.1
 
 Release date: 2011-01-21

data/README.rdoc

@@ -7,12 +7,11 @@
 Capybara aims to simplify the process of integration testing Rack applications,
 such as Rails, Sinatra or Merb. Capybara simulates how a real user would
 interact with a web application. It is agnostic about the driver running your
-tests and currently comes bundled with rack-test, Culerity, Celerity and Selenium
-support built in. env.js support is available as the
-{capybara-envjs gem}[http://github.com/smparkes/capybara-envjs].
+tests and currently comes with Rack::Test and Selenium support built in.
+HtmlUnit and env.js are supported through external gems.
 
-Online documentation is availbable
-{at rdoc.info}[http://rdoc.info/projects/jnicklas/capybara].
+A complete reference is available at
+{at rubydoc.info}[http://rubydoc.info/github/jnicklas/capybara/master].
 
 == Install:
 
@@ -36,6 +35,7 @@ you make.
 
 Capybara uses bundler in development. To set up a development environment, simply do:
 
+    git submodule update --init
     gem install bundler --pre
     bundle install
 
@@ -70,8 +70,8 @@ driver that supports JavaScript, Capybara makes this easy: simply tag the
 scenario (or feature) with <tt>@javascript</tt>:
 
     @javascript
-    Scenario: do something AJAXy
-      When I click the AJAX link
+    Scenario: do something Ajaxy
+      When I click the Ajax link
       ...
 
 You can change which driver Capybara uses for JavaScript:
@@ -83,14 +83,18 @@ There are also explicit <tt>@selenium</tt>, <tt>@culerity</tt> and
 
 == Using Capybara with RSpec
 
-If you prefer RSpec to using Cucumber, you can use the built in RSpec support:
+If you prefer RSpec to using Cucumber, you can use the built in RSpec support
+by adding the following line (typically to your <tt>spec_helper.rb</tt> file):
 
     require 'capybara/rspec'
-    Capybara.app = MyRackApp
 
 You can now use it in your examples:
 
-    describe "the signup process", :type => :acceptance do
+    describe "the signup process", :type => :request do
+      before :each do
+        User.make(:email => 'user@example.com', :password => 'caplin')
+      end
+
       it "signs me in" do
         within("#session") do
           fill_in 'Login', :with => 'user@example.com'
@@ -100,8 +104,16 @@ You can now use it in your examples:
       end
     end
 
-Capybara is only included for examples which have the type
-<tt>:acceptance</tt>.
+Capybara is only included for examples with <tt>:type => :request</tt> (or
+<tt>:acceptance</tt> for compatibility).
+
+If you use the <tt>rspec-rails</tt> gem, <tt>:type => :request</tt> is
+automatically set on all files under <tt>spec/requests</tt>. Essentially, these
+are Capybara-enhanced Rails request specs, so it's a good idea to place your
+Capybara specs here because within request specs you gain a few additional
+features, such as the ability to refer to named route helpers. If you do not
+need these, then you may simply use <tt>spec/acceptance</tt> and you will still
+get access to Capybara methods.
 
 RSpec's metadata feature can be used to switch to a different driver. Use
 <tt>:js => true</tt> to switch to the javascript driver, or provide a
@@ -112,46 +124,146 @@ RSpec's metadata feature can be used to switch to a different driver. Use
       it 'will switch to one specific driver', :driver => :celerity
     end
 
+Capybara also comes with a built in DSL for creating descriptive acceptance tests:
+
+    feature "Signing up" do
+      background do
+        User.make(:email => 'user@example.com', :password => 'caplin')
+      end
+
+      scenario "Signing in with correct credentials" do
+        within("#session") do
+          fill_in 'Login', :with => 'user@example.com'
+          fill_in 'Password', :with => 'caplin'
+        end
+        click_link 'Sign in'
+      end
+    end
+
+Essentially, this is just a shortcut for making a request spec, where
+<tt>feature</tt> is a shortcut for <tt>describe ..., :type => :request</tt>,
+<tt>background</tt> is an alias for <tt>before :each</tt>, and <tt>scenario</tt>
+is an alias for <tt>it</tt>/<tt>example</tt>. Again, you are encouraged to place
+these within <tt>spec/requests</tt> rather than <tt>spec/acceptance</tt>.
+
 Note that Capybara's built in RSpec support only works with RSpec 2.0 or later.
 You'll need to roll your own for earlier versions of RSpec.
 
-== Default and current driver
+== Using Capybara with Test::Unit
+
+To use Capybara with Test::Unit, include the DSL (<tt>include Capybara</tt> up
+until version 0.4.x, <tt>include Capybara::DSL</tt> for newer versions) in
+whatever test class you are using.  For example, if your classes derive from
+<tt>ActionDispatch::IntegrationTest</tt>, use
+
+    class ActionDispatch::IntegrationTest
+      include Capybara::DSL
+    end
+
+Test::Unit does not support selecting the driver through test metadata, but you
+can switch the driver for specific classes using the <tt>setup</tt> and
+<tt>teardown</tt> methods.  See the section "Selecting the Driver".
+
+== Using Capybara with Ruby on Rails
 
-You can set up a default driver for your features. For example if you'd prefer
-to run Selenium, you could do:
+If you are using the Rails framework, add this line to automatically configure
+Capybara to test against your Rails application:
 
     require 'capybara/rails'
-    require 'capybara/cucumber'
+
+== Using Capybara with Rack
+
+If you're using Capybara with a non-Rails Rack application, set
+<tt>Capybara.app</tt> to your application class:
+
+    Capybara.app = MyRackApp
+
+== Drivers
+
+Capybara uses the same DSL to drive a variety of browser and headless drivers.
+
+=== Selecting the Driver
+
+By default, Capybara uses the <tt>:rack_test</tt> driver, which is fast but does not
+support JavaScript.  You can set up a different default driver for your
+features. For example if you'd prefer to run everything in Selenium, you could
+do:
+
     Capybara.default_driver = :selenium
 
-You can change the driver temporarily:
+However, if you are using RSpec or Cucumber, you may instead want to consider
+leaving the faster <tt>:rack_test</tt> as the +default_driver+, and marking only those
+tests that require a JavaScript-capable driver using <tt>:js => true</tt> or
+<tt>@javascript</tt>, respectively.  By default, JavaScript tests are run using the
+<tt>:selenium</tt> driver.  You can change this by setting
+<tt>Capybara.javascript_driver</tt>.
+
+You can also change the driver temporarily (typically in the Before/setup and
+After/teardown blocks):
+
+    Capybara.current_driver = :culerity  # temporarily select different driver
+    ... tests ...
+    Capybara.use_default_driver  # switch back to default driver
+
+Note that switching the driver creates a new session, so you may not be able to
+switch in the middle of a test.
+
+=== RackTest
+
+RackTest is Capybara's default driver. It is written in pure Ruby and does not
+have any support for executing JavaScript. Since the RackTest driver works
+directly agains the Rack interface, it does not need any server to be started,
+it can work directly work against any Rack app. 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. You cannot
+use the RackTest driver to test a remote application.
+{capybara-mechanize}[https://github.com/jeroenvandijk/capybara-mechanize]
+intends to provide a similar driver which works against remote servers, it is a
+separate project.
+
+RackTest can be configured with a set of headers like this:
+
+    Capybara.register_driver :rack_test do |app|
+      Capybara::RackTest::Driver.new(app, :browser => :chrome)
+    end
+
+See the section on adding and configuring drivers.
 
-    Capybara.current_driver = :culerity
-    Capybara.use_default_driver
+=== Selenium
 
-You can do this in Before and After blocks to temporarily switch to a different
-driver. Note that switching driver creates a new session, so you may not be able
-to switch in the middle of a Scenario.
+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. Provided Firefox is installed, everything is set up for you,
+and you should be able to start using Selenium right away.
 
-== Selenium
+By default Capybara tries to synchronize Ajax requests, so it will wait for
+Ajax requests to finish after you've interacted with the page. You can switch
+off this behaviour by setting the driver option <tt>:resynchronize</tt> to
+<tt>false</tt>. See the section on configuring drivers.
 
-At the moment, Capybara supports Webdriver, also called Selenium 2.0, *not*
-Selenium RC. Provided Firefox is installed, everything is set up for you, and
-you should be able to start using Selenium right away.
+Note: Selenium does not support transactional fixtures; see the section
+"Transactional Fixtures" below.
 
-== Celerity
+=== HtmlUnit
 
-Celerity only runs on JRuby, so you'll need to install the celerity gem under
-JRuby:
+There are three different drivers, maintained as external gems, that you can
+use to drive {HtmlUnit}[http://htmlunit.sourceforge.net/]:
 
-   jruby -S gem install celerity
+* {Akephalos}[https://github.com/bernerdschaefer/akephalos] might be the best
+  HtmlUnit driver right now.
 
-== Culerity
+* {Celerity}[https://github.com/sobrinho/capybara-celerity] only runs on JRuby,
+  so you'll need to install the celerity gem under JRuby: <tt>jruby -S gem
+  install celerity</tt>
 
-Install celerity as noted above, make sure JRuby is in your path. Note that
-Culerity doesn't seem to be working under Ruby 1.9 at the moment.
+* {Culerity}[https://github.com/sobrinho/capybara-culerity]: Install celerity
+  as noted above, and make sure that JRuby is in your path. Note that Culerity
+  does not seem to be working under Ruby 1.9 at the moment.
 
-== env.js
+Note: HtmlUnit does not support transactional fixtures; see the section
+"Transactional Fixtures" below.
+
+=== env.js
 
 The {capybara-envjs driver}[http://github.com/smparkes/capybara-envjs]
 uses the envjs gem ({GitHub}[http://github.com/smparkes/env-js],
@@ -163,17 +275,22 @@ JavaScript outside the browser. The driver is installed by installing the capyba
 More info about the driver and env.js are available through the links above. The envjs gem only supports
 Ruby 1.8.7 at this time.
 
-== The DSL
+Note: Envjs does not support transactional fixtures; see the section
+"Transactional Fixtures" below.
 
-Capybara's DSL is inspired by Webrat. While backwards compatibility is retained
-in a lot of cases, there are certain important differences.
+== The DSL
 
-Unlike in Webrat, all searches in Capybara are *case sensitive*. This is because
-Capybara heavily uses XPath, which doesn't support case insensitivity.
+Capybara's DSL (domain-specific language) is inspired by Webrat. While
+backwards compatibility is retained in a lot of cases, there are certain
+important differences.  Unlike in Webrat, all searches in Capybara are *case
+sensitive*. This is because Capybara heavily uses XPath, which doesn't support
+case insensitivity.
 
 === Navigating
 
-You can use the <tt>visit</tt> method to navigate to other pages:
+You can use the
+<tt>{visit}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#visit-instance_method]</tt>
+method to navigate to other pages:
 
     visit('/projects')
     visit(post_comments_path(post))
@@ -181,29 +298,34 @@ You can use the <tt>visit</tt> method to navigate to other pages:
 The visit method only takes a single parameter, the request method is *always*
 GET.
 
-You can get the current path of the browsing session for test assertions:
+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:
 
     current_path.should == post_comments_path(post)
 
 === Clicking links and buttons
 
+<em>Full reference: {Capybara::Node::Actions}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions]</em>
+
 You can interact with the webapp by following links and buttons. Capybara
 automatically follows any redirects, and submits forms associated with buttons.
 
     click_link('id-of-link')
     click_link('Link Text')
     click_button('Save')
-    click_link_or_button('Link Text')
-    click_link_or_button('Button Value')
+    click_on('Link Text')  # clicks on either links or buttons
+    click_on('Button Value')
 
 === Interacting with forms
 
-Forms are everywhere in webapps, there are a number of tools for interacting
-with the various form elements:
+<em>Full reference: {Capybara::Node::Actions}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions]</em>
+
+There are a number of tools for interacting with form elements:
 
     fill_in('First Name', :with => 'John')
     fill_in('Password', :with => 'Seekrit')
-    fill_in('Description', :with => 'Really Long Text…')
+    fill_in('Description', :with => 'Really Long Text...')
     choose('A Radio Button')
     check('A Checkbox')
     uncheck('A Checkbox')
@@ -212,6 +334,8 @@ with the various form elements:
 
 === Querying
 
+<em>Full reference: {Capybara::Node::Matchers}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Matchers]</em>
+
 Capybara has a rich set of options for querying the page for the existence of
 certain elements, and working with and manipulating those elements.
 
@@ -223,7 +347,7 @@ certain elements, and working with and manipulating those elements.
     page.has_css?('table tr.foo')
     page.has_content?('foo')
 
-You can these use with RSpec's magic matchers:
+You can use these with RSpec's magic matchers:
 
     page.should have_selector('table tr')
     page.should have_selector(:xpath, '//table/tr')
@@ -238,8 +362,16 @@ Note that <tt>page.should have_no_xpath</tt> is preferred over
 <tt>page.should_not have_xpath</tt>. Read the section on asynchronous JavaScript
 for an explanation.
 
+If all else fails, you can also use the
+<tt>{page.html}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#html-instance_method]</tt>
+method to test against the raw HTML:
+
+    page.html.should match /<span>.../i
+
 === Finding
 
+<em>Full reference: {Capybara::Node::Finders}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Finders]</em>
+
 You can also find specific elements, in order to manipulate them:
 
     find_field('First Name').value
@@ -251,7 +383,7 @@ You can also find specific elements, in order to manipulate them:
     all('a').each { |a| a[:href] }
 
 Note that <tt>find</tt> 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.
+Ajax section. If the element does not appear it will raise an error.
 
 These elements all have all the Capybara DSL methods available, so you can restrict them
 to specific parts of the page:
@@ -263,8 +395,9 @@ to specific parts of the page:
 
 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</tt> method. Optionally you can
-specify which kind of selector to use.
+this purpose you can use the generic
+<tt>{within}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session#within-instance_method]</tt>
+method. Optionally you can specify which kind of selector to use.
 
     within("li#employee") do
       fill_in 'Name', :with => 'Jimmy'
@@ -304,7 +437,18 @@ look at it:
 
     save_and_open_page
 
-== Asynchronous JavaScript (AJAX and friends)
+== Transactional fixtures
+
+Transactional fixtures only work in the default Rack::Test driver, but not for
+other drivers like Selenium.  Cucumber takes care of this automatically, but
+with Test::Unit or RSpec, you may have to use the
+{database_cleaner}[https://github.com/bmabey/database_cleaner] gem.  See {this
+explanation}[https://groups.google.com/d/msg/ruby-capybara/JI6JrirL9gM/R6YiXj4gi_UJ]
+(and code for {solution
+2}[http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/#comment-220]
+and {solution 3}[http://pastie.org/1745020]) for details.
+
+== 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
@@ -318,7 +462,7 @@ When issuing instructions to the DSL such as:
     page.should have_content('baz')
 
 If clicking on the *foo* link causes triggers an asynchronous process, such as
-an AJAX request, which, when complete will add the *bar* link to the page,
+an Ajax request, which, when complete will add the *bar* link to the page,
 clicking on the *bar* link would be expeced to fail, since that link doesn't
 exist yet. However Capybara is smart enought to retry finding the link for a
 brief period of time before giving up and throwing an error. The same is true of
@@ -339,10 +483,10 @@ asynchronous process has not yet removed the element from the page, it would
 therefore fail, even though the code might be working correctly. The latter
 correctly waits for the element to disappear from the page.
 
-== Using the DSL outside cucumber
+== Using the DSL in unsupported testing frameworks
+
+You can mix the DSL into any context by including +Capybara::DSL+:
 
-You can mix the DSL into any context, for example you could use it in RSpec
-examples. Just load the DSL and include it anywhere:
 
     require 'capybara'
     require 'capybara/dsl'
@@ -350,7 +494,7 @@ examples. Just load the DSL and include it anywhere:
     Capybara.default_driver = :culerity
 
     module MyModule
-      include Capybara
+      include Capybara::DSL
 
       def login!
         within("//form[@id='session']") do
@@ -372,8 +516,9 @@ setting app_host:
     ...
     visit('/')
 
-Note that rack-test does not support running against a remote server. With
-drivers that support it, you can also visit any URL directly:
+Note that the default driver (<tt>:rack_test</tt>) does not support running
+against a remote server. With drivers that support it, you can also visit any
+URL directly:
 
     visit('http://www.google.com')
 
@@ -385,7 +530,9 @@ remote application:
 
 == Using the sessions manually
 
-For ultimate control, you can instantiate and use a session manually.
+For ultimate control, you can instantiate and use a
+{Session}[http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Session]
+manually.
 
     require 'capybara'
 
@@ -399,8 +546,8 @@ For ultimate control, you can instantiate and use a session manually.
 == XPath, CSS and selectors
 
 Capybara does not try to guess what kind of selector you are going to give it,
-if you want to use XPath with your 'within' declarations for example, you'll need
-to do:
+and will always use CSS by default.  If you want to use XPath, you'll need to
+do:
 
     within(:xpath, '//ul/li') { ... }
     find(:xpath, '//ul/li').text
@@ -474,14 +621,14 @@ an API to tweak those drivers with whatever settings you want, or to add your ow
 drivers. This is how to switch the selenium driver to use chrome:
 
     Capybara.register_driver :selenium do |app|
-      Capybara::Driver::Selenium.new(app, :browser => :chrome)
+      Capybara::Selenium::Driver.new(app, :browser => :chrome)
     end
 
 However, it's also possible to give this a different name, so tests can switch
 between using different browsers effortlessly:
 
     Capybara.register_driver :selenium_chrome do |app|
-      Capybara::Driver::Selenium.new(app, :browser => :chrome)
+      Capybara::Selenium::Driver.new(app, :browser => :chrome)
     end
 
 Whatever is returned from the block should conform to the API described by
@@ -503,7 +650,7 @@ additional info about how the underlying driver can be configured.
 
 * Freezing time: It's common practice to mock out the Time so that features
   that depend on the current Date work as expected. This can be problematic,
-  since Capybara's AJAX timing uses the system time, resulting in Capybara
+  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 plugins which allow you to travel in time, rather than freeze time.
   One such plugin is {Timecop}[http://github.com/jtrupiano/timecop].