rspec-rails 2.13.0 → 2.13.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: b2867278a722c089dbb2bd8f6063ecb479760f05
+  data.tar.gz: bb564009cc97a8fb65e1088e71d3c0d0538bebd3
+SHA512:
+  metadata.gz: e030efde0376019bc0f8397c361c73aebf1ce81ba9e62412ef702c56e74c1f3145a43feb7b41e9dcc482e2cd1bd8c1b831c7620348c83bae9e844dffda224fd4
+  data.tar.gz: 8397abcbfdf655a2c8c9daa3891b03e4a4cf38ff1f60b6106cdf8b7240d29ff496883360ea16ee4c74a48fb61f89599b1cad36157402d33a7380c7a6bb304f5e

data/Capybara.md

@@ -3,8 +3,6 @@ its Capybara::DSL (visit/page) and Capybara::RSpecMatchers to the
 examples in the applicable directories, which differ slightly between
 Capybara 1.x and Capybara >= 2.x.
 
-Note that you need to require "capybara/rspec" for this integration to work.
-
 ## Capybara::DSL
 
 Adds the `visit` and `page` methods, which work together to simulate a
@@ -12,7 +10,7 @@ GET request and provide access to the result (via `page`).
 
 ## Capybara::RSpecMatchers
 
-Exposes matchers used to specify expected HTML content (e.g. `have_selector`).
+Exposes matchers used to specify expected HTML content (e.g. `should_not have_selector` will work correctly).
 
 ## Capybara 1.x
 

data/Changelog.md

@@ -1,3 +1,17 @@
+### 2.13.1
+[full changelog](http://github.com/rspec/rspec-rails/compare/v2.13.0...v2.13.1)
+
+Bug fixes
+
+* View specs are no longer generated if no template engine is specified (Kevin
+  Glowacz)
+* `ActionController::Base.allow_forgery_protection` is set to its original
+  value after each example. (Mark Dimas)
+* `patch` is supported in routing specs. (Chris Your)
+* Routing assertions are supported in controller specs in Rails 4. (Andy
+  Lindeman)
+* Fix spacing in the install generator template (Taiki ONO)
+
 ### 2.13.0 / 2013-02-23
 [full changelog](http://github.com/rspec/rspec-rails/compare/v2.12.2...v2.13.0)
 

data/README.md

@@ -1,34 +1,58 @@
 # rspec-rails [![Build Status](https://secure.travis-ci.org/rspec/rspec-rails.png?branch=master)](http://travis-ci.org/rspec/rspec-rails) [![Code Climate](https://codeclimate.com/github/rspec/rspec-rails.png)](https://codeclimate.com/github/rspec/rspec-rails)
 
-**rspec-rails 2** is a testing framework for Rails 3.x and 4.x.
+**rspec-rails** is a testing framework for Rails 3.x and 4.x.
 
-Use **[rspec-rails 1](http://github.com/dchelimsky/rspec-rails)** for Rails 2.x.
+Use **[rspec-rails 1.x](http://github.com/dchelimsky/rspec-rails)** for Rails
+2.x.
 
-## Install
+## Installation
 
-Add `rspec-rails` to the `:test` and `:development` groups in the Gemfile:
+Add `rspec-rails` to **both** the `:development` and `:test` groups in the
+`Gemfile`:
 
 ```ruby
-group :test, :development do
-  gem "rspec-rails", "~> 2.0"
+group :development, :test do
+  gem 'rspec-rails', '~> 2.0'
 end
 ```
 
-It needs to be in the `:development` group to expose generators and rake
-tasks without having to type `RAILS_ENV=test`.
+Download and install by running:
 
-Now you can run:
+```
+bundle install
+```
+
+Initialize the `spec/` directory (where specs will reside) with:
 
 ```
 rails generate rspec:install
 ```
 
-This adds the spec directory and some skeleton files, including
-the "rake spec" task.
+To run your specs, use the `rspec` command:
+
+```
+bundle exec rspec
+
+# Run only model specs
+bundle exec rspec spec/models
+
+# Run only specs for AccountsController
+bundle exec rspec spec/controllers/accounts_controller_spec.rb
+```
+
+Specs can also be run via `rake spec`, though this command may be slower to
+start than the `rspec` command.
+
+In Rails 4, you may want to create a binstub for the `rspec` command so it can
+be run via `bin/rspec`:
+
+```
+bundle binstubs rspec-core
+```
 
 ### Generators
 
-Once installed, RSpec will generate spec file instead of Test::Unit test files
+Once installed, RSpec will generate spec files instead of Test::Unit test files
 when commands like `rails generate model` and `rails generate controller` are
 used.
 
@@ -67,7 +91,7 @@ describe PostsController do
     it "responds successfully with an HTTP 200 status code" do
       get :index
       expect(response).to be_success
-      expect(response.code).to eq(200)
+      expect(response.status).to eq(200)
     end
 
     it "renders the index template" do
@@ -97,7 +121,8 @@ spec](#feature-specs).
 
 ## <a id="request-spec"></a>Request Specs
 
-Request specs live in spec/requests, spec/api and spec/integration, and mix in behavior
+Request specs live in spec/requests, spec/features, spec/api and
+spec/integration, and mix in behavior
 [ActionDispatch::Integration::Runner](http://api.rubyonrails.org/classes/ActionDispatch/Integration/Runner.html),
 which is the basis for [Rails' integration
 tests](http://guides.rubyonrails.org/testing.html#integration-testing).  The
@@ -123,7 +148,9 @@ end
 ```
 
 This example uses only standard Rails and RSpec API's, but many RSpec/Rails
-users like to use extension libraries like [FactoryGirl](https://github.com/thoughtbot/factory_girl) and [Capybara](https://github.com/jnicklas/capybara):
+users like to use extension libraries like
+[FactoryGirl](https://github.com/thoughtbot/factory_girl) and
+[Capybara](https://github.com/jnicklas/capybara):
 
 ```ruby
 require 'spec_helper'
@@ -145,7 +172,10 @@ which can be encoded into the underlying factory definition without requiring
 changes to this example.
 
 Among other benefits, Capybara binds the form post to the generated HTML, which
-means we don't need to specify them separately.
+means we don't need to specify them separately.  Note that Capybara's DSL as
+shown is, by default, only available in specs in the spec/features directory.
+For more information, see the [Capybara integration
+docs](http://rubydoc.info/gems/rspec-rails/file/Capybara.md).
 
 There are several other Ruby libs that implement the factory pattern or provide
 a DSL for request specs (a.k.a. acceptance or integration specs), but

data/features/Transactions.md

@@ -36,11 +36,11 @@ already ran. For example:
       end
 
       it "does something" do
-        @widget.should do_something
+        expect(@widget).to do_something
       end
         
       it "does something else" do
-        @widget.should do_something_else
+        expect(@widget).to do_something_else
       end
     end
 

data/features/Upgrade.md

@@ -60,6 +60,10 @@ This needs to move from before the action to after. For example:
     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

data/features/controller_specs/Cookies.md

@@ -20,7 +20,7 @@ the following guidelines:
 # spec
 request.cookies['foo'] = 'bar'
 get :some_action
-response.cookies['foo'].should eq('modified bar')
+expect(response.cookies['foo']).to eq('modified bar')
 
 # controller
 def some_action

data/features/controller_specs/README.md

@@ -12,15 +12,15 @@ specify expected outcomes such as:
 * cookies sent back with the response
 
 To specify outcomes, you can use:
-    
-* standard rspec matchers (`response.code.should eq(200)`)
-* standard test/unit assertions (`assert_equal 200, response.code`)
+
+* standard rspec matchers (`expect(response.status).to eq(200)`)
+* standard test/unit assertions (`assert_equal 200, response.status`)
 * rails assertions (`assert_response 200`)
 * rails-specific matchers:
-  * `response.should render_template (wraps assert_template)`
-  * `response.should redirect_to (wraps assert_redirected_to)`
-  * `assigns(:widget).should be_a_new(Widget)`
-    
+  * `expect(response).to render_template(wraps assert_template)`
+  * `expect(response).to redirect_to(wraps assert_redirected_to)`
+  * `expect(assigns(:widget)).to be_a_new(Widget)`
+
 ## Examples
 
     describe TeamsController do
@@ -28,12 +28,12 @@ To specify outcomes, you can use:
         it "assigns @teams" do
           team = Team.create
           get :index
-          assigns(:teams).should eq([team])
+          expect(assigns(:teams)).to eq([team])
         end
 
         it "renders the index template" do
           get :index
-          response.should render_template("index")
+          expect(response).to render_template("index")
         end
       end
     end

data/features/controller_specs/controller_spec.feature

@@ -9,7 +9,7 @@ Feature: controller spec
         describe "GET index" do
           it "has a 200 status code" do
             get :index
-            expect(response.code).to eq("200")
+            expect(response.status).to eq(200)
           end
         end
       end

data/features/controller_specs/engine_routes.feature

@@ -0,0 +1,51 @@
+Feature: engine routes for controllers
+
+  Controller specs can specify the routeset that will be used for the example
+  group. This is most useful when testing Rails engines.
+
+  @unsupported-on-rails-3-0
+  Scenario: specify engine route
+    Given a file named "spec/controllers/widgets_controller_spec.rb" with:
+    """ruby
+    require "spec_helper"
+
+    # A very simple Rails engine
+    module MyEngine
+      class Engine < ::Rails::Engine
+        isolate_namespace MyEngine
+      end
+
+      Engine.routes.draw do
+        resources :widgets, :only => [:show] do
+          get :random, :on => :collection
+        end
+      end
+
+      class WidgetsController < ::ActionController::Base
+        def random
+          @random_widget = Widget.all.shuffle.first
+          redirect_to widget_path(@random_widget)
+        end
+
+        def show
+          @widget = Widget.find(params[:id])
+          render :text => @widget.name
+        end
+      end
+    end
+
+    describe MyEngine::WidgetsController do
+      routes { MyEngine::Engine.routes }
+
+      it "redirects to a random widget" do
+        widget1 = Widget.create!(:name => "Widget 1")
+        widget2 = Widget.create!(:name => "Widget 2")
+
+        get :random
+        expect(response).to be_redirect
+        expect(response).to redirect_to(assigns(:random_widget))
+      end
+    end
+    """
+    When I run `rspec spec`
+    Then the examples should all pass

data/features/helper_specs/helper_spec.feature

@@ -94,3 +94,29 @@ Feature: helper spec
       """
     When I run `rspec spec/helpers/widgets_helper_spec.rb`
     Then the examples should all pass
+
+  Scenario: url helpers are defined
+    Given a file named "spec/helpers/widgets_helper_spec.rb" with:
+    """ruby
+    require "spec_helper"
+
+    describe WidgetsHelper do
+      describe "#link_to_widget" do
+        it "links to a widget using its name" do
+          widget = Widget.create!(:name => "This Widget")
+          expect(helper.link_to_widget(widget)).to include("This Widget")
+          expect(helper.link_to_widget(widget)).to include(widget_path(widget))
+        end
+      end
+    end
+    """
+    And a file named "app/helpers/widgets_helper.rb" with:
+    """ruby
+    module WidgetsHelper
+      def link_to_widget(widget)
+        link_to(widget.name, widget_path(widget))
+      end
+    end
+    """
+    When I run `rspec spec/helpers/widgets_helper_spec.rb`
+    Then the examples should all pass

data/features/matchers/README.md

@@ -4,15 +4,15 @@ rspec-compatible wrappers for Rails' assertions.
 ### redirects
 
     # delegates to assert_redirected_to
-    response.should redirect_to(path)
+    expect(response).to redirect_to(path)
 
 ### templates
 
     # delegates to assert_template
-    response.should render_template(template_name)
+    expect(response).to render_template(template_name)
 
 ### assigned objects
 
     # passes if assigns(:widget) is an instance of Widget
     # and it is not persisted
-    assigns(:widget).should be_a_new(Widget)
+    expect(assigns(:widget)).to be_a_new(Widget)

data/features/model_specs/errors_on.feature

@@ -10,7 +10,7 @@ Feature: errors_on
         validates_presence_of :name
 
         # In Rails 4, mass assignment protection is implemented on controllers
-        attr_accessible :name if Rails.version < '4'
+        attr_accessible :name if RSpec::Rails.rails_version_satisfied_by?('< 4.0.0.beta1')
 
         validates_length_of :name, :minimum => 10, :on => :publication
       end

data/features/routing_specs/README.md

@@ -5,13 +5,12 @@ Simple apps with nothing but standard RESTful routes won't get much value from
 routing specs, but they can provide significant value when used to specify
 customized routes, like vanity links, slugs, etc.
 
-    { :get => "/articles/2012/11/when-to-use-routing-specs" }.
-      should route_to(
-        :controller => "articles",
-        :month => "2012-11",
-        :slug => "when-to-use-routing-specs"
-      )
+    expect(:get => "/articles/2012/11/when-to-use-routing-specs").to route_to(
+      :controller => "articles",
+      :month => "2012-11",
+      :slug => "when-to-use-routing-specs"
+    )
 
 They are also valuable for routes that should not be available:
 
-    { :delete => "/accounts/37" }.should_not be_routable
+    expect(:delete => "/accounts/37").not_to be_routable

data/features/routing_specs/engine_routes.feature

@@ -0,0 +1,38 @@
+Feature: engine routes
+
+  Routing specs can specify the routeset that will be used for the example
+  group. This is most useful when testing Rails engines.
+
+  @unsupported-on-rails-3-0
+  Scenario: specify engine route
+    Given a file named "spec/routing/engine_routes_spec.rb" with:
+    """ruby
+    require "spec_helper"
+
+    # A very simple Rails engine
+    module MyEngine
+      class Engine < ::Rails::Engine
+        isolate_namespace MyEngine
+      end
+
+      Engine.routes.draw do
+        resources :widgets, :only => [:index]
+      end
+
+      class WidgetsController < ::ActionController::Base
+        def index
+        end
+      end
+    end
+
+    describe MyEngine::WidgetsController do
+      routes { MyEngine::Engine.routes }
+
+      it "routes to the list of all widgets" do
+        expect(:get => widgets_path).
+          to route_to(:controller => "my_engine/widgets", :action => "index")
+      end
+    end
+    """
+    When I run `rspec spec`
+    Then the examples should all pass

data/features/support/rails_versions.rb

@@ -0,0 +1,4 @@
+Around "@unsupported-on-rails-3-0" do |scenario, block|
+  require 'rails'
+  block.call unless ::Rails.version.to_s.start_with?("3.0")
+end

data/lib/generators/rspec.rb

@@ -1,4 +1,5 @@
 require 'rails/generators/named_base'
+require 'rspec/rails/rails_version'
 
 module Rspec
   module Generators
@@ -7,7 +8,7 @@ module Rspec
         @_rspec_source_root ||= File.expand_path(File.join(File.dirname(__FILE__), 'rspec', generator_name, 'templates'))
       end
 
-      if ::Rails.version < '3.1'
+      if RSpec::Rails.rails_version_satisfied_by?('< 3.1')
         def module_namespacing
           yield if block_given?
         end

data/lib/generators/rspec/controller/controller_generator.rb

@@ -18,7 +18,7 @@ module Rspec
 
       def generate_view_specs
         return if actions.empty?
-        return unless options[:view_specs]
+        return unless options[:view_specs] && options[:template_engine]
 
         empty_directory File.join("spec", "views", file_path)
 

data/lib/generators/rspec/install/install_generator.rb

@@ -1,3 +1,5 @@
+require 'rspec/rails/rails_version'
+
 module Rspec
   module Generators
     class InstallGenerator < ::Rails::Generators::Base