rspec-rails 3.0.0.beta2 → 3.0.0.rc1

data/features/model_specs/errors_on.feature

@@ -1,51 +0,0 @@
-Feature: errors_on
-
-  Scenario: with one validation error
-    Given a file named "spec/models/widget_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      class ValidatingWidget < ActiveRecord::Base
-        self.table_name = :widgets
-        validates_presence_of :name
-
-        # In Rails 4, mass assignment protection is implemented on controllers
-        attr_accessible :name if ::ActiveRecord::VERSION::STRING < '4'
-
-        validates_length_of :name, :minimum => 10, :on => :publication
-      end
-
-      describe ValidatingWidget do
-        it "fails validation with no name (using error_on)" do
-          expect(ValidatingWidget.new).to have(1).error_on(:name)
-        end
-
-        it "fails validation with no name (using errors_on)" do
-          expect(ValidatingWidget.new).to have(1).errors_on(:name)
-        end
-
-        it "fails validation with no name expecting a specific message" do
-          expect(ValidatingWidget.new.errors_on(:name)).to include("can't be blank")
-        end
-
-        it "fails validation with a short name (using a validation context)" do
-          expect(ValidatingWidget.new(:name => "too short")).
-            to have(1).errors_on(:name, :context => :publication)
-        end
-
-        it "passes validation with a longer name (using a validation context)" do
-          expect(ValidatingWidget.new(:name => "a longer name")).
-            to have(0).errors_on(:name, :context => :publication)
-        end
-
-        it "passes validation with a name (using 0)" do
-          expect(ValidatingWidget.new(:name => "liquid nitrogen")).to have(0).errors_on(:name)
-        end
-
-        it "passes validation with a name (using :no)" do
-          expect(ValidatingWidget.new(:name => "liquid nitrogen")).to have(:no).errors_on(:name)
-        end
-      end
-      """
-    When I run `rspec spec/models/widget_spec.rb`
-    Then the examples should all pass

data/features/model_specs/records.feature

@@ -1,27 +0,0 @@
-Feature: records
-
-  Scenario: asserting number of records
-    Given a file named "spec/models/widget_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe Widget do
-        it "has no widgets in the database" do
-          expect(Widget).to have(:no).records
-          expect(Widget).to have(0).records
-        end
-
-        it "has one record" do
-          Widget.create!(:name => "Cog")
-          expect(Widget).to have(1).record
-        end
-
-        it "counts only records that match a query" do
-          Widget.create!(:name => "Cog")
-          expect(Widget.where(:name => "Cog")).to have(1).record
-          expect(Widget.where(:name => "Wheel")).to have(0).records
-        end
-      end
-      """
-    When I run `rspec spec/models/widget_spec.rb`
-    Then the examples should all pass

data/features/model_specs/transactional_examples.feature

@@ -1,109 +0,0 @@
-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:
-      """ruby
-      require "spec_helper"
-
-      describe Widget do
-        it "has none to begin with" do
-          expect(Widget.count).to eq 0
-        end
-
-        it "has one after adding one" do
-          Widget.create
-          expect(Widget.count).to eq 1
-        end
-
-        it "has none after one was created in a previous example" do
-          expect(Widget.count).to eq 0
-        end
-      end
-      """
-    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:
-      """ruby
-      require "spec_helper"
-
-      RSpec.configure do |c|
-        c.use_transactional_examples = true
-      end
-
-      describe Widget do
-        it "has none to begin with" do
-          expect(Widget.count).to eq 0
-        end
-
-        it "has one after adding one" do
-          Widget.create
-          expect(Widget.count).to eq 1
-        end
-
-        it "has none after one was created in a previous example" do
-          expect(Widget.count).to eq 0
-        end
-      end
-      """
-    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:
-      """ruby
-      require "spec_helper"
-
-      RSpec.configure do |c|
-        c.use_transactional_examples = false
-        c.order = "defined"
-      end
-
-      describe Widget do
-        it "has none to begin with" do
-          expect(Widget.count).to eq 0
-        end
-
-        it "has one after adding one" do
-          Widget.create
-          expect(Widget.count).to eq 1
-        end
-
-        it "has one after one was created in a previous example" do
-          expect(Widget.count).to eq 1
-        end
-
-        after(:all) { Widget.destroy_all }
-      end
-      """
-    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:
-      """ruby
-      require "spec_helper"
-
-      describe Thing do
-        fixtures :things
-        it "fixture method defined" do
-          things(:one)
-        end
-      end
-      """
-    Given a file named "spec/fixtures/things.yml" with:
-      """
-      one:
-        name: MyString
-      """
-    When I run `rspec spec/models/thing_spec.rb`
-    Then the examples should all pass
-
-
-

data/features/request_specs/request_spec.feature

@@ -1,49 +0,0 @@
-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.
-
-  [Capybara](http://github.com/jnicklas/capybara) is no longer supported in
-  request specs as of Capybara 2.0.0. The recommended way to use Capybara is
-  with [feature specs](../feature-specs/feature-spec).
-
-  Scenario: specify managing a Widget with Rails integration methods
-    Given a file named "spec/requests/widget_management_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe "Widget management" do
-
-        it "creates a Widget and redirects to the Widget's page" do
-          get "/widgets/new"
-          expect(response).to render_template(:new)
-
-          post "/widgets", :widget => {:name => "My Widget"}
-
-          expect(response).to redirect_to(assigns(:widget))
-          follow_redirect!
-
-          expect(response).to render_template(:show)
-          expect(response.body).to 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

@@ -1,16 +0,0 @@
-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.
-
-    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:
-
-    expect(:delete => "/accounts/37").not_to be_routable

data/features/routing_specs/be_routable_matcher.feature

@@ -1,80 +0,0 @@
-Feature: be_routable matcher
-
-  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 not be routable (fails)
-    Given a file named "spec/routing/widgets_routing_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "does not route to widgets" do
-          expect(:get => "/widgets").not_to be_routable
-        end
-      end
-      """
-
-    When I run `rspec spec/routing/widgets_routing_spec.rb`
-    Then the output should contain "1 example, 1 failure"
-
-  Scenario: specify non-routeable route should not be routable (passes)
-    Given a file named "spec/routing/widgets_routing_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "does not route to widgets/foo/bar" do
-          expect(:get => "/widgets/foo/bar").not_to be_routable
-        end
-      end
-      """
-
-    When I run `rspec spec/routing/widgets_routing_spec.rb`
-    Then the examples should all pass
-
-  Scenario: specify routeable route should be routable (passes)
-    Given a file named "spec/routing/widgets_routing_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "routes to /widgets" do
-          expect(:get => "/widgets").to be_routable
-        end
-      end
-      """
-
-    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:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "routes to widgets/foo/bar" do
-          expect(:get => "/widgets/foo/bar").to be_routable
-        end
-      end
-      """
-
-    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
-    Given a file named "spec/controllers/widgets_controller_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe WidgetsController do
-        it "routes to /widgets" do
-          expect(:get => "/widgets").to be_routable
-        end
-      end
-      """
-
-    When I run `rspec spec/controllers/widgets_controller_spec.rb`
-    Then the examples should all pass

data/features/routing_specs/engine_routes.feature

@@ -1,38 +0,0 @@
-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/routing_specs/named_routes.feature

@@ -1,18 +0,0 @@
-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:
-      """ruby
-      require "spec_helper"
-
-      describe "routes to the widgets controller" do
-        it "routes a named route" do
-          expect(:get => new_widget_path).
-            to 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

@@ -1,90 +0,0 @@
-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.
-
-      expect(get("/")).to route_to("welcome#index") # new in 2.6.0
-
-      or
-
-      expect(:get => "/").to route_to(:controller => "welcome")
-
-  Scenario: passing route spec with shortcut syntax
-    Given a file named "spec/routing/widgets_routing_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "routes /widgets to the widgets controller" do
-          expect(get("/widgets")).
-            to 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:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "routes /widgets to the widgets controller" do
-          expect(:get => "/widgets").
-            to 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:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "routes /widgets/foo to the /foo action" do
-          expect(get("/widgets/foo")).to route_to("widgets#foo")
-        end
-      end
-      """
-
-    When I run `rspec spec/routing/widgets_routing_spec.rb`
-    Then the output should contain "1 failure"
-
-  Scenario: route spec for a namespaced route with shortcut specifier
-    Given a file named "spec/routing/admin_routing_spec.rb" with:
-      """ruby
-      require "spec_helper"
-
-      describe "routes for Widgets" do
-        it "routes /admin/accounts to the admin/accounts controller" do
-          expect(get("/admin/accounts")).
-            to route_to("admin/accounts#index")
-        end
-      end
-      """
-
-    When I run `rspec spec/routing/admin_routing_spec.rb`
-    Then the examples should all pass
-
-  Scenario: route spec for a namespaced route with verbose specifier
-   Given a file named "spec/routing/admin_routing_spec.rb" with:
-     """ruby
-     require "spec_helper"
-
-     describe "routes for Widgets" do
-       it "routes /admin/accounts to the admin/accounts controller" do
-         expect(get("/admin/accounts")).
-           to route_to(:controller => "admin/accounts", :action => "index")
-       end
-     end
-     """
-
-   When I run `rspec spec/routing/admin_routing_spec.rb`
-   Then the examples should all pass