rspec-rails 2.14.2 → 2.99.0.beta1

checksums.yaml

@@ -1,7 +1,15 @@
 ---
-SHA1:
-  metadata.gz: 6741d6e7967f02aced3fb72537ba85386350d57f
-  data.tar.gz: 1afb7b53f425c8d4444fe480212d94ddcade704b
-SHA512:
-  metadata.gz: 76c3968ca67e9054656f0e855f000637458c9318c68b82bdb9965781ebf4073f7ce43a699368a74479dd6db02a75712ac78af7851b73683d062d61acfa2892d9
-  data.tar.gz: 00c97b1e0c7873f74330710bf1cdca9862f3a174826ec897141624f85949196d678cb12827d18aa67cc773e22b844cedeb39b7fbb04121a1220e62eb7b897084
+!binary "U0hBMQ==":
+  metadata.gz: !binary |-
+    NzMxYzE1NGZhMDdhYTFkNTc5Y2MyNTU1M2IxMWUyOGY1MzMwZTU5NA==
+  data.tar.gz: !binary |-
+    ODA5YjFlY2UzYjk0YTNhNTkwMmE2ZTBhMDZjNWU5OGI4NTY3YzFmYQ==
+!binary "U0hBNTEy":
+  metadata.gz: !binary |-
+    MWQwNDc3ZjhkNzI2Zjc5YzU1YjJhOWRjMmJhNDJkODQ4YTE4MjBlMzY1YWE2
+    YzI5MjQ1ZjJjNDg2MDQyMzA5YTFhMTQ1OTE0ZDllOTYyMjliZmZhOTU2MDI0
+    MmQzNGUwNTZjZWM1NGViNzAxOGY4YjgxMTI1OTQ4OTZhN2FlMDk=
+  data.tar.gz: !binary |-
+    OWM4ZGMwODc0NTRlNDYwNjNmYWQ5MmM3ZTVmMTY3ODVjNjY4M2IzNGI4MTA4
+    N2E2MmU2OGE1NDZjYTZhYjU1ZDM1MjAxOTUwMmMxZGY4ODgxMGEwZmQzOGJh
+    MTBkZjBlNjYwOWVkN2JiOTFiZjMxNmQ4ODgxYTAyZWEyODkwNzY=

data/Changelog.md

@@ -1,14 +1,14 @@
-### 2.14.2 / 2014-03-22
-[full changelog](http://github.com/rspec/rspec-rails/compare/v2.14.1...v2.14.2)
+### 2.99.0.beta1 / 2013-11-07
+[full changelog](http://github.com/rspec/rspec-rails/compare/v2.14.0...v2.99.0.beta1)
 
-Bug fixes
+Deprecations
+
+* Deprecates autotest integration in favor of the `rspec-autotest` gem. (Andy
+  Lindeman)
 
-* Loads ActiveSupport properly to support changes in Rails 4.1. (Andy Lindeman)
-* Anonymous controllers inherit from `ActionController::Base` if `ApplicationController`
-  is not present. (Jon Rowe)
+Enhancements
 
-### 2.14.1 / 2013-12-29
-[full changelog](http://github.com/rspec/rspec-rails/compare/v2.14.0...v2.14.1)
+* Supports Rails 4.1 and Minitest 5. (Patrick Van Stee)
 
 Bug fixes
 
@@ -17,10 +17,8 @@ Bug fixes
 * Where possible, check against the version of ActiveRecord, rather than
   Rails. It is possible to use some of rspec-rails without all of Rails.
   (Darryl Pogue)
-* Supports Rails 4.1 and Minitest 5. (Patrick Van Stee, Andy Lindeman)
 * Explicitly depends on `activemodel`. This allows libraries that do not bring
   in all of `rails` to use `rspec-rails`. (John Firebaugh)
-* Use `__send__` rather than `send` to prevent naming collisions (Bradley Schaefer)
 
 ### 2.14.0 / 2013-07-06
 [full changelog](http://github.com/rspec/rspec-rails/compare/v2.14.0.rc1...v2.14.0)

data/features/Autotest.md

@@ -0,0 +1,24 @@
+The `rspec:install` generator creates a `.rspec` file, which tells RSpec to
+tell Autotest that you're using RSpec. You'll also need to add the ZenTest and
+autotest-rails gems to your Gemfile:
+
+    gem "ZenTest", "~> 4.4.2"
+    gem "autotest-rails", "~> 4.1.0"
+
+If all of the gems in your Gemfile are installed in system gems, you can just
+type
+
+    autotest
+
+If Bundler is managing any gems for you directly (i.e. you've got `:git` or
+`:path` attributes in the Gemfile), however, you may need to run
+
+    bundle exec autotest
+
+If you do, you require Autotest's bundler plugin in a `.autotest` file in the
+project root directory or your home directory:
+
+    require "autotest/bundler"
+
+Now you can just type `autotest`, it should prefix the generated shell command
+with `bundle exec`.

data/features/Generators.md

@@ -0,0 +1,24 @@
+RSpec spec are normally generated alongside other application components.
+For instance, `rails generate model` will also generate an RSpec spec file
+for the model.
+
+Note that the generators are there to help you get started, but they are no
+substitute for writing your own examples, and they are only guaranteed to work
+out of the box for with Rails' defaults.
+
+RSpec generators can also be run independently. For instance,
+
+    rails generate rspec:model widget
+
+will create a new spec file in `spec/models/widget_spec.rb`.
+
+The same generator pattern is available for all specs:
+
+* scaffold
+* model
+* controller
+* helper
+* view
+* mailer
+* observer
+* integration

data/features/GettingStarted.md

@@ -0,0 +1,84 @@
+Install Rails-3
+
+    $ gem install rails -v "~> 3.0.0"
+
+### Generate an app
+
+    $ rails new example
+    $ cd example
+
+### Add rspec-rails to the Gemfile
+
+    $ echo 'gem "rspec-rails", :group => [:development, :test]' >> Gemfile
+
+### Install the bundle
+
+    $ bundle install
+
+### Bootstrap RSpec
+
+    $ rails generate rspec:install
+
+### Generate a scaffold
+
+    $ rails generate scaffold Widgets name:string
+
+This generates files in the `app` and `spec` directories. The files in the
+`app` directory are generated by Rails, and Rails delegates the generation of
+the files in the `spec` directory to RSpec.
+
+### Run migrations
+
+    $ rake db:migrate && rake db:test:prepare
+
+### Run RSpec
+
+    $ rake spec
+
+or
+
+    $ rspec spec --format documentation
+
+If all went well, you should see output ending with:
+
+    29 examples, 0 failures, 2 pending
+
+This output also includes the following controller spec:
+
+    WidgetsController
+      GET index
+        assigns all widgets as @widgets
+      GET show
+        assigns the requested widget as @widget
+      GET new
+        assigns a new widget as @widget
+      GET edit
+        assigns the requested widget as @widget
+      POST create
+        with valid params
+          creates a new Widget
+          assigns a newly created widget as @widget
+          redirects to the created widget
+        with invalid params
+          assigns a newly created but unsaved widget as @widget
+          re-renders the 'new' template
+      PUT update
+        with valid params
+          updates the requested widget
+          assigns the requested widget as @widget
+          redirects to the widget
+        with invalid params
+          assigns the widget as @widget
+          re-renders the 'edit' template
+      DELETE destroy
+        destroys the requested widget
+        redirects to the widgets list
+
+Output like this can help to quickly gain a high level understanding of how an
+object behaves. It also exposes which cases have been specified and which have
+not. Note the balance between the examples for the `create` and `update`
+actions. If the `redirects to the widget` example was missing from one or the
+other, it would be easy to spot.
+
+Take a look at the generated `spec/controllers/widgets_controller_spec.rb` to
+get a sense of how to organize your specs to generate output like this.

data/features/README.md

@@ -0,0 +1,56 @@
+rspec-rails extends Rails' built-in testing framework to support rspec examples
+for requests, controllers, models, views, helpers, mailers and routing.
+
+## Rails-3
+
+rspec-rails-2 supports rails-3.0.0 and later. For earlier versions of Rails,
+you need [rspec-rails-1.3](http://rspec.info).
+
+## Install
+
+    gem install rspec-rails
+
+This installs the following gems:
+
+    rspec
+    rspec-core
+    rspec-expectations
+    rspec-mocks
+    rspec-rails
+
+## Configure
+
+Add rspec-rails to the :test and :development groups in the Gemfile:
+
+    group :test, :development do
+      gem "rspec-rails", "~> 2.4"
+    end
+
+It needs to be in the :development group to expose generators and rake tasks
+without having to type RAILS_ENV=test.
+
+Now you can run:
+
+    script/rails generate rspec:install
+
+This adds the spec directory and some skeleton files, including a .rspec
+file.
+
+## Webrat and Capybara
+
+You can choose between webrat or capybara for simulating a browser, automating
+a browser, or setting expectations using the matchers they supply. Just add
+your preference to the Gemfile:
+
+    gem "webrat"
+    gem "capybara"
+
+## Issues
+
+The documentation for rspec-rails is a work in progress. We'll be adding
+Cucumber features over time, and clarifying existing ones.  If you have
+specific features you'd like to see added, find the existing documentation
+incomplete or confusing, or, better yet, wish to write a missing Cucumber
+feature yourself, please [submit an
+issue](http://github.com/rspec/rspec-rails/issues) or a [pull
+request](http://github.com/rspec/rspec-rails).

data/features/RailsVersions.md

@@ -0,0 +1,4 @@
+    rails version | rspec-rails version
+    2.3           | 1.3.4
+    3.0           | >= 2.0
+    3.1           | >= 2.6

data/features/Transactions.md

@@ -0,0 +1,84 @@
+When you run `rails generate rspec:install`, the `spec/spec_helper.rb` file
+includes the following configuration:
+
+    RSpec.configure do |config|
+      config.use_transactional_fixtures = true
+    end
+
+The name of this setting is a bit misleading. What it really means in Rails
+is "run every test method within a transaction." In the context of rspec-rails,
+it means "run every example within a transaction."
+
+The idea is to start each example with a clean database, create whatever data
+is necessary for that example, and then remove that data by simply rolling back
+the transaction at the end of the example.
+
+### Disabling transactions
+
+If you prefer to manage the data yourself, or using another tool like
+[database_cleaner](https://github.com/bmabey/database_cleaner) to do it for you,
+simply tell RSpec to tell Rails not to manage transactions:
+
+    RSpec.configure do |config|
+      config.use_transactional_fixtures = false
+    end
+
+### Data created in `before(:each)` are rolled back
+
+Any data you create in a `before(:each)` hook will be rolled back at the end of
+the example. This is a good thing because it means that each example is
+isolated from state that would otherwise be left around by the examples that
+already ran. For example:
+
+    describe Widget do
+      before(:each) do
+        @widget = Widget.create
+      end
+
+      it "does something" do
+        expect(@widget).to do_something
+      end
+        
+      it "does something else" do
+        expect(@widget).to do_something_else
+      end
+    end
+
+The `@widget` is recreated in each of the two examples above, so each example
+has a different object, _and_ the underlying data is rolled back so the data
+backing the `@widget` in each example is new.
+        
+### Data created in `before(:all)` are _not_ rolled back
+
+`before(:all)` hooks are invoked before the transaction is opened. You can use
+this to speed things up by creating data once before any example in a group is
+run, however, this introduces a number of complications and you should only do
+this if you have a firm grasp of the implications. Here are a couple of
+guidelines:
+
+1.  Be sure to clean up any data in an `after(:all)` hook:
+
+        before(:all) do
+          @widget = Widget.create!
+        end
+
+        after(:all) do
+          @widget.destroy
+        end
+
+    If you don't do that, you'll leave data lying around that will eventually
+    interfere with other examples.
+
+2.  Reload the object in a `before(:each)` hook.
+
+        before(:all) do
+          @widget = Widget.create!
+        end
+
+        before(:each) do
+          @widget.reload
+        end
+
+      Even though database updates in each example will be rolled back, the
+      object won't _know_ about those rollbacks so the object and its backing
+      data can easily get out of sync.

data/features/Upgrade.md

@@ -0,0 +1,121 @@
+# Upgrading from rspec-rails-1.x to rspec-rails-2.
+
+This is a work in progress. Please submit errata, missing steps, or patches to
+the [rspec-rails issue tracker](https://github.com/rspec/rspec-rails/issues).
+
+## Rake tasks
+
+Delete lib/tasks/rspec.rake, if present. Rake tasks now live in the rspec-rails
+gem.
+
+## `spec_helper.rb`
+
+There were a few changes to the generated `spec/spec_helper.rb` file. We
+recommend the following:
+
+1. set aside a copy of your existing `spec/spec_helper.rb` file.
+2. run `rails generate rspec:install`
+3. copy any customizations from your old spec_helper to the new one
+
+If you prefer to make the changes manually in the existing spec_helper, here
+is what you need to change:
+
+    # rspec-1
+    require 'spec/autorun'
+
+    Spec::Runner.configure do |config|
+      ...
+    end
+
+    # rspec-2
+    require 'rspec/rails'
+
+    RSpec.configure do |config|
+      ...
+    end
+
+## Controller specs
+
+### isolation from view templates
+
+By default, controller specs do _not_ render view templates. This keeps
+controller specs isolated from the content of views and their requirements.
+
+NOTE that the template must exist, but it will not be rendered.  This is
+different from rspec-rails-1.x, in which the template didn't need to exist, but
+ActionController makes a number of new decisions in Rails 3 based on the
+existence of the template. To keep the RSpec code free of monkey patches, and
+to keep the rspec user experience simpler, we decided that this would be a fair
+trade-off.
+
+### `response.should render_template`
+
+This needs to move from before the action to after. For example:
+
+    # rspec-rails-1
+    controller.should render_template("edit")
+    get :edit, :id => "37"
+
+    # rspec-rails-2
+    get :edit, :id => "37"
+    response.should render_template("edit")
+
+    # rspec-rails-2 with expect syntax
+    get :edit, :id => "37"
+    expect(response).to render_template("edit")
+
+rspec-1 had to monkey patch Rails to get render_template to work before the
+action, and this broke a couple of times with Rails releases (requiring urgent
+fix releases in RSpec). Part of the philosophy of rspec-rails-2 is to rely on
+public APIs in Rails as much as possible. In this case, `render_template`
+delegates directly to Rails' `assert_template`, which only works after the
+action.
+
+## View specs
+
+### `view.should render_template`
+
+Rails changed the way it renders partials, so to set an expectation that a
+partial gets rendered, you need
+
+    render
+    view.should render_template(:partial => "widget/_row")
+
+### stub_template
+
+Introduced in rspec-rails-2.2, simulates the presence of view templates on the
+file system. This supports isolation from partials rendered by the vew template
+that is the subject of a view example:
+
+    stub_template "widgets/_widget.html.erb" => "This Content"
+
+### No more `have_tag` or `have_text`
+
+Before Webrat came along, rspec-rails had its own `have_tag` and `have_text`
+matchers that wrapped Rails' `assert_select`. Webrat included replacements for
+these methods, as well as new matchers (`have_selector` and `have_xpath`), all
+of which rely on Nokogiri to do its work, and are far less brittle than RSpec's
+`have_tag`.
+
+Capybara has similar matchers, which will soon be available view specs (they
+are already available in controller specs with `render_views`).
+
+Given the brittleness of RSpec's `have_tag` and `have_text` matchers and the
+presence of new Webrat and Capybara matchers that do a better job, `have_tag`
+and `have_text` were not included in rspec-rails-2.
+
+## Mocks, stubs, doubles
+
+### as_new_record
+
+Earlier versions of the view generators generated stub_model with `:new_record?
+=> true`. That is no longer recognized in rspec-rails-2, so you need to change
+this:
+
+    stub_model(Widget, :new_record? => true)
+
+to this:
+
+    stub_model(Widget).as_new_record
+
+Generators in 2.0.0 final release will do the latter.