rspec-rails 2.0.0.beta.22 → 2.6.0

data/features/matchers/README.md

@@ -0,0 +1,4 @@
+rspec-rails offers a number of custom matchers, most of which are
+rspec-compatible wrappers for Rails' assertions.
+
+

data/features/matchers/new_record_matcher.feature

@@ -1,10 +1,10 @@
 Feature: be_a_new matcher
 
-  The be_a_new matcher accepts a class and passes if the subject is an instance
-  of that class that returns true to new_record?
+  The `be_a_new` matcher accepts a class and passes if the subject is an
+  instance of that class that returns false to persisted?
 
-  You can also call "with" on be_a_new with a hash of attributes to specify the
-  subject has equal attributes.
+  You can also chain `with` on `be_a_new` with a hash of attributes to specify
+  the subject has equal attributes.
 
   Scenario: example spec with four be_a_new possibilities 
     Given a file named "spec/models/widget_spec.rb" with:
@@ -24,47 +24,5 @@ Feature: be_a_new matcher
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "4 examples, 0 failures"
-
-  Scenario: example spec using be_a_new.with
-    Given a file named "spec/models/widget_spec.rb" with:
-      """
-      require "spec_helper"
-
-      class Widget < ActiveRecord::Base
-        establish_connection :adapter => 'sqlite3',
-                             :database => ':memory:'
-
-        connection.execute <<-eosql
-          CREATE TABLE widgets (
-            foo_id integer,
-            number integer
-          )
-        eosql
-      end
-
-      describe Widget do
-        context "when initialized with attributes" do
-          subject { Widget.new(:foo_id => 1, :number => 1) }
-
-          it "has all of the attributes" do
-            should be_a_new(Widget).with(:foo_id => 1, :number => 1)
-          end
-
-          it "has one of the attributes" do
-            should be_a_new(Widget).with(:foo_id => 1)
-          end
-
-          it "has none of the attributes" do
-            should_not be_a_new(Widget).with(:blah => 'blah')
-          end
-
-          it "has one of the attribute values not the same" do
-            should_not be_a_new(Widget).with(:foo_id => 2)
-          end
-        end
-      end
-      """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "4 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass

data/features/matchers/redirect_to_matcher.feature

@@ -1,9 +1,8 @@
 Feature: redirect_to matcher
 
-  The redirect_to matcher is used to specify that the redirect called
-  in the latest action ended with the intended behaviour. Essentially,
-  it delegates to "assert_redirect". For more info, please check out
-  the Rails documentation on this method.
+  The `redirect_to` matcher is used to specify that a request redirects to a
+  given template or action.  It delegates to
+  [`assert_redirected_to`](http://api.rubyonrails.org/classes/ActionDispatch/Assertions/ResponseAssertions.html#method-i-assert_redirected_to).
 
   It is available in controller specs (spec/controllers) and request
   specs (spec/requests).
@@ -37,5 +36,5 @@ Feature: redirect_to matcher
         end
       end
       """
-    When I run "rspec spec/controllers/widgets_controller_spec.rb"
-    Then the output should contain "4 examples, 0 failures"
+    When I run `rspec spec/controllers/widgets_controller_spec.rb`
+    Then the examples should all pass

data/features/matchers/render_template_matcher.feature

@@ -1,10 +1,13 @@
 Feature: render_template matcher
 
-  This matcher just delegates to the Rails assertion method
-  "assert_template". For complete info on the available options,
-  please take a look at the Rails documentation.
+  The `render_template` matcher is used to specify that a request renders a
+  given template.  It delegates to
+  [`assert_template`](http://api.rubyonrails.org/classes/ActionController/TemplateAssertions.html#method-i-assert_template)
 
-  This method is available in spec/controllers and spec/requests.
+  It is available in controller specs (spec/controllers) and request
+  specs (spec/requests).
+
+  NOTE: use `redirect_to(:action => 'new')` for redirects, not `render_template`.
 
   Scenario: render_template with three possible options
     Given a file named "spec/controllers/gadgets_spec.rb" with:
@@ -12,14 +15,14 @@ Feature: render_template matcher
       require "spec_helper"
 
       describe GadgetsController do
-        describe "#index" do
+        describe "GET #index" do
           subject { get :index }
 
-          specify { should render_template(:index) }
-          specify { should render_template("index") }
-          specify { should render_template("gadgets/index") }
+          it { should render_template(:index) }
+          it { should render_template("index") }
+          it { should render_template("gadgets/index") }
         end
       end
       """
-    When I run "rspec spec/controllers/gadgets_spec.rb"
-    Then the output should contain "3 examples, 0 failures"
+    When I run `rspec spec/controllers/gadgets_spec.rb`
+    Then the examples should all pass

data/features/mocks/mock_model.feature

@@ -1,8 +1,8 @@
 Feature: mock_model
 
-  The mock_model method generates a test double object that acts like an
-  Active Model model. This is different from the stub_model method which
-  generates an instance of a real ActiveModel class.
+  The mock_model method generates a test double that acts like an Active Model
+  model. This is different from the stub_model method which generates an
+  instance of a real ActiveModel class.
 
   The benefit of mock_model over stub_model is that its a true double, so the
   examples are not dependent on the behaviour (or mis-behaviour), or even the
@@ -36,8 +36,8 @@ Feature: mock_model
         end
       end
       """
-    When I run "rspec spec/models/car_spec.rb"
-    Then the output should contain "3 examples, 0 failures"
+    When I run `rspec spec/models/car_spec.rb`
+    Then the examples should all pass
 
   Scenario: passing a string that represents an existing constant
     Given a file named "spec/models/widget_spec.rb" with:
@@ -51,8 +51,8 @@ Feature: mock_model
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
 
   Scenario: passing a class that does not extend ActiveModel::Naming
     Given a file named "spec/models/string_spec.rb" with:
@@ -65,8 +65,8 @@ Feature: mock_model
         end
       end
       """
-    When I run "rspec spec/models/string_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/models/string_spec.rb`
+    Then the examples should all pass
 
   Scenario: passing an Active Record constant
     Given a file named "spec/models/widget_spec.rb" with:
@@ -94,8 +94,8 @@ Feature: mock_model
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "4 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
 
   Scenario: passing an Active Record constant with method stubs
     Given a file named "spec/models/widget_spec.rb" with:
@@ -127,5 +127,21 @@ Feature: mock_model
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "3 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
+
+  Scenario: mock_model outside rails
+    Given a file named "mock_model_outside_rails_spec.rb" with:
+      """
+      require 'rspec/rails/mocks'
+
+      describe "Foo" do
+        it "is mockable" do
+          foo = mock_model("Foo")
+          foo.id.should eq(1001)
+          foo.to_param.should eq("1001")
+        end
+      end
+      """
+    When I run `rspec mock_model_outside_rails_spec.rb`
+    Then the examples should all pass

data/features/mocks/stub_model.feature

@@ -34,8 +34,8 @@ Feature: stub_model
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "4 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
     
   Scenario: passing an Active Record constant with a block of stubs
     Given a file named "spec/models/widget_spec.rb" with:
@@ -54,5 +54,5 @@ Feature: stub_model
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass

data/features/model_specs/README.md

@@ -0,0 +1,21 @@
+Model specs live in `spec/models` or any example group with
+`:type => :model`.
+
+A model spec is a thin wrapper for an ActiveSupport::TestCase, and includes all
+of the behavior and assertions that it provides, in addition to RSpec's own
+behavior and expectations.
+
+## Examples
+
+    require "spec_helper"
+    
+    describe Post do
+      context "with 2 or more comments" do
+        it "orders them in reverse" do
+          post = Post.create
+          comment1 = post.comment("first")
+          comment2 = post.comment("second")
+          post.reload.comments.should eq([comment2, comment1])
+        end
+      end
+    end

data/features/model_specs/errors_on.feature

@@ -28,5 +28,5 @@ Feature: errors_on
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "4 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass

data/features/model_specs/transactional_examples.feature

@@ -1,5 +1,10 @@
 Feature: transactional examples
 
+  By default rspec executes each individual example in a transaction.
+
+  You can also explicitly enable/disable transactions the configuration
+  property 'use_transactional_examples'.
+
   Scenario: run in transactions (default)
     Given a file named "spec/models/widget_spec.rb" with:
       """
@@ -20,8 +25,8 @@ Feature: transactional examples
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "3 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
 
   Scenario: run in transactions (explicit)
     Given a file named "spec/models/widget_spec.rb" with:
@@ -47,8 +52,8 @@ Feature: transactional examples
         end
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "3 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
 
   Scenario: disable transactions (explicit)
     Given a file named "spec/models/widget_spec.rb" with:
@@ -76,15 +81,15 @@ Feature: transactional examples
         after(:all) { Widget.destroy_all }
       end
       """
-    When I run "rspec spec/models/widget_spec.rb"
-    Then the output should contain "3 examples, 0 failures"
+    When I run `rspec spec/models/widget_spec.rb`
+    Then the examples should all pass
 
   Scenario: run in transactions with fixture
     Given a file named "spec/models/thing_spec.rb" with:
       """
       require "spec_helper"
 
-      describe Thing do 
+      describe Thing do
         fixtures :things
         it "fixture method defined" do
           things(:one)
@@ -96,8 +101,8 @@ Feature: transactional examples
       one:
         name: MyString
       """
-    When I run "rspec spec/models/thing_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/models/thing_spec.rb`
+    Then the examples should all pass
 
 
 

data/features/request_specs/request_spec.feature

@@ -0,0 +1,49 @@
+Feature: request spec
+
+  Request specs provide a thin wrapper around Rails' integration tests, and are
+  designed to drive behavior through the full stack, including routing
+  (provided by Rails) and without stubbing (that's up to you).
+
+  With request specs, you can:
+
+  * specify a single request
+  * specify multiple requests across multiple controllers
+  * specify multiple requests across multiple sessions
+
+  Check the rails documentation on integration tests for more information.
+
+  RSpec provides two matchers that delegate to Rails assertions:
+
+      render_template # delegates to assert_template
+      redirect_to     # delegates to assert_redirected_to
+
+  Check the Rails docs for details on these methods as well.
+
+  If you would like to use webrat or capybara with your request specs, all you
+  have to do is include one of them in your Gemfile and RSpec will
+  automatically load them in a request spec.
+
+  Scenario: specify managing a Widget with Rails integration methods
+    Given a file named "spec/requests/widget_management_spec.rb" with:
+      """
+      require "spec_helper"
+
+      describe "Widget management" do
+
+        it "creates a Widget and redirects to the Widget's page" do
+          get "/widgets/new"
+          response.should render_template(:new)
+
+          post "/widgets", :widget => {:name => "My Widget"}
+
+          response.should redirect_to(assigns(:widget))
+          follow_redirect!
+
+          response.should render_template(:show)
+          response.body.should include("Widget was successfully created.")
+        end
+
+      end
+      """
+    When I run `rspec spec/requests/widget_management_spec.rb`
+    Then the example should pass

data/features/routing_specs/README.md

@@ -0,0 +1,17 @@
+Routing specs live in the `spec/routing` directory, or any example group with
+`:type => :routing`.
+
+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"
+      )
+
+They are also valuable for routes that should not be available:
+
+    { :delete => "/accounts/37" }.should_not be_routable

data/features/{matchers → routing_specs}/be_routable_matcher.feature

@@ -1,67 +1,67 @@
 Feature: be_routable matcher
 
-  The be_routable matcher is intended for use with should_not to specify that a
-  given route should_not be_routable. It is available in routing specs (in
-  spec/routing) and controller specs (in spec/controller).
+  The `be_routable` matcher is best used with `should_not` to specify that a
+  given route should not be routable. It is available in routing specs (in
+  spec/routing) and controller specs (in spec/controllers).
 
-  Scenario: specify routeable route should be routable (passes)
+  Scenario: specify routeable route should not be routable (fails)
     Given a file named "spec/routing/widgets_routing_spec.rb" with:
       """
       require "spec_helper"
 
-      describe WidgetsController do
-        it "routes to /widgets" do
-          { :get => "/widgets" }.should be_routable
+      describe "routes for Widgets" do
+        it "does not route to widgets" do
+          { :get => "/widgets" }.should_not be_routable
         end
       end
       """
 
-    When I run "rspec spec/routing/widgets_routing_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
+    Then the output should contain "1 example, 1 failure"
 
-  Scenario: specify routeable route should not be routable (fails)
+  Scenario: specify non-routeable route should not be routable (passes)
     Given a file named "spec/routing/widgets_routing_spec.rb" with:
       """
       require "spec_helper"
 
-      describe WidgetsController do
-        it "does not route to widgets" do
-          { :get => "/widgets" }.should_not be_routable
+      describe "routes for Widgets" do
+        it "does not route to widgets/foo/bar" do
+          { :get => "/widgets/foo/bar" }.should_not be_routable
         end
       end
       """
 
-    When I run "rspec spec/routing/widgets_routing_spec.rb"
-    Then the output should contain "1 example, 1 failure"
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
+    Then the examples should all pass
 
-  Scenario: specify non-routeable route should not be routable (passes)
+  Scenario: specify routeable route should be routable (passes)
     Given a file named "spec/routing/widgets_routing_spec.rb" with:
       """
       require "spec_helper"
 
-      describe WidgetsController do
-        it "does not route to widgets/foo/bar" do
-          { :get => "/widgets/foo/bar" }.should_not be_routable
+      describe "routes for Widgets" do
+        it "routes to /widgets" do
+          { :get => "/widgets" }.should be_routable
         end
       end
       """
 
-    When I run "rspec spec/routing/widgets_routing_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
+    Then the examples should all pass
 
   Scenario: specify non-routeable route should be routable (fails)
     Given a file named "spec/routing/widgets_routing_spec.rb" with:
       """
       require "spec_helper"
 
-      describe WidgetsController do
+      describe "routes for Widgets" do
         it "routes to widgets/foo/bar" do
           { :get => "/widgets/foo/bar" }.should be_routable
         end
       end
       """
 
-    When I run "rspec spec/routing/widgets_routing_spec.rb"
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
     Then the output should contain "1 example, 1 failure"
 
   Scenario: be_routable in a controller spec
@@ -76,5 +76,5 @@ Feature: be_routable matcher
       end
       """
 
-    When I run "rspec spec/controllers/widgets_controller_spec.rb"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/controllers/widgets_controller_spec.rb`
+    Then the examples should all pass

data/features/routing_specs/named_routes.feature

@@ -0,0 +1,18 @@
+Feature: named routes
+
+  Routing specs have access to named routes.
+
+  Scenario: access named route
+    Given a file named "spec/routing/widget_routes_spec.rb" with:
+      """
+      require "spec_helper"
+
+      describe "routes to the widgets controller" do
+        it "routes a named route" do
+          {:get => new_widget_path}.
+            should route_to(:controller => "widgets", :action => "new")
+        end
+      end
+      """
+    When I run `rspec spec`
+    Then the examples should all pass

data/features/routing_specs/route_to_matcher.feature

@@ -0,0 +1,58 @@
+Feature: route_to matcher
+
+  The `route_to` matcher specifies that a request (verb + path) is routable.
+  It is most valuable when specifying routes other than standard RESTful
+  routes.
+
+      get("/").should route_to("welcome#index") # new in 2.6.0
+
+      or
+
+      { :get => "/" }.should route_to(:controller => "welcome")
+
+  Scenario: passing route spec with shortcut syntax
+    Given a file named "spec/routing/widgets_routing_spec.rb" with:
+      """
+      require "spec_helper"
+
+      describe "routes for Widgets" do
+        it "routes /widgets to the widgets controller" do
+          get("/widgets").
+            should route_to("widgets#index")
+        end
+      end
+      """
+
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
+    Then the examples should all pass
+
+  Scenario: passing route spec with verbose syntax
+    Given a file named "spec/routing/widgets_routing_spec.rb" with:
+      """
+      require "spec_helper"
+
+      describe "routes for Widgets" do
+        it "routes /widgets to the widgets controller" do
+          { :get => "/widgets" }.
+            should route_to(:controller => "widgets", :action => "index")
+        end
+      end
+      """
+
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
+    Then the examples should all pass
+
+  Scenario: route spec for a route that doesn't exist (fails)
+    Given a file named "spec/routing/widgets_routing_spec.rb" with:
+      """
+      require "spec_helper"
+
+      describe "routes for Widgets" do
+        it "routes /widgets/foo to the /foo action" do
+          get("/widgets/foo").should route_to("widgets#foo")
+        end
+      end
+      """
+
+    When I run `rspec spec/routing/widgets_routing_spec.rb`
+    Then the output should contain "1 failure"

data/features/step_definitions/additional_cli_steps.rb

@@ -0,0 +1,4 @@
+Then /^the example(s)? should( all)? pass$/ do |_, _|
+  Then %q{the output should contain "0 failures"}
+  Then %q{the exit status should be 0}
+end

data/features/support/env.rb

@@ -1,5 +1,16 @@
-require 'aruba'
-require 'webrat'
+require 'aruba/cucumber'
+
+module ArubaExt
+  def run(cmd)
+    super(cmd =~ /^rspec/ ? "bundle exec #{cmd}" : cmd)
+  end
+end
+
+World(ArubaExt)
+
+Before do
+  @aruba_timeout_seconds = 10
+end
 
 unless File.directory?('./tmp/example_app')
   system "rake generate:app generate:stuff"
@@ -31,9 +42,7 @@ Before do
   }
 
   Dir['tmp/example_app/*'].each do |file_or_dir|
-    if file_or_dir =~ /Gemfile/
-      copy(file_or_dir)
-    elsif !(file_or_dir =~ /spec$/)
+    if !(file_or_dir =~ /spec$/)
       write_symlink(file_or_dir)
     end
   end
@@ -41,5 +50,4 @@ Before do
   ["spec/spec_helper.rb"].each do |file_or_dir|
     write_symlink("tmp/example_app/#{file_or_dir}")
   end
-
 end

data/features/view_specs/inferred_controller_path.feature

@@ -11,8 +11,8 @@ Feature: view spec infers controller path and action
         end
       end
       """
-    When I run "rspec spec/views"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/views`
+    Then the examples should all pass
 
   Scenario: infer action
     Given a file named "spec/views/widgets/new.html.erb_spec.rb" with:
@@ -25,8 +25,8 @@ Feature: view spec infers controller path and action
         end
       end
       """
-    When I run "rspec spec/views"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/views`
+    Then the examples should all pass
 
   Scenario: do not infer action in a partial
     Given a file named "spec/views/widgets/_form.html.erb_spec.rb" with:
@@ -39,6 +39,6 @@ Feature: view spec infers controller path and action
         end
       end
       """
-    When I run "rspec spec/views"
-    Then the output should contain "1 example, 0 failures"
+    When I run `rspec spec/views`
+    Then the examples should all pass