Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Comparing changes

Choose two branches to see what's changed or to start a new pull request. If you need to, you can also compare across forks.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also compare across forks.
base fork: rspec/rspec-rails
...
head fork: rspec/rspec-rails
  • 14 commits
  • 23 files changed
  • 0 commit comments
  • 2 contributors
View
8 History.md
@@ -1,5 +1,13 @@
## rspec-rails-2 release history
+### 2.3.1 / 2010-12-16
+
+[full changelog](http://github.com/rspec/rspec-rails/compare/v2.3.0...v2.3.1)
+
+* Bug fixes
+ * respond_to? correctly handles 2 args
+ * scaffold generator no longer fails on autotest directory
+
### 2.3.0 / 2010-12-12
[full changelog](http://github.com/rspec/rspec-rails/compare/v2.2.1...v2.3.0)
View
6 README.md
@@ -60,7 +60,7 @@ out of the box for the default scenario (`ActiveRecord` + `Webrat`).
### Autotest
-The `rspec:install` generator creates an `./autotest/discover.rb` file, which
+The `rspec:install` generator creates an `.rspec` file, which
tells Autotest that you're using RSpec and Rails. You'll also need to add the
autotest (not autotest-rails) gem to your Gemfile:
@@ -142,8 +142,8 @@ You can use RSpec expectations/matchers or Test::Unit assertions.
## `render_views`
By default, controller specs do not render views. This supports specifying
controllers without concern for whether the views they render work correctly
-(NOTE: the template must exist, unlike rspec-rails-1. See Upgrade.markdown for
-more information about this). If you prefer to render the views (a la Rails'
+(NOTE: the template must exist, unlike rspec-rails-1. See Upgrade.md for more
+information about this). If you prefer to render the views (a la Rails'
functional tests), you can use the `render_views` declaration in each example
group:
View
4 Rakefile
@@ -105,10 +105,10 @@ namespace :clobber do
end
end
-desc "Push cukes to relishapp using the relish-client-gem"
+desc "Push docs/cukes to relishapp using the relish-client-gem"
task :relish, :version do |t, args|
raise "rake relish[VERSION]" unless args[:version]
- sh "relish push --organization rspec --project rspec-rails -v #{args[:version]}"
+ sh "relish push rspec/rspec-rails:#{args[:version]}"
end
task :default => [:spec, "clobber:app", "generate:app", "generate:stuff", :smoke, :cucumber]
View
0  Upgrade.markdown → Upgrade.md
File renamed without changes
View
18 features/.nav
@@ -1,10 +1,9 @@
+- Upgrade.md
+- Generators.md
+- Autotest.md
+- transactional_examples.feature
- model_specs:
- - transactional_examples.feature
- errors_on.feature
-- view_specs:
- - view_spec.feature
- - stub_template.feature
- - inferred_controller_path.feature
- controller_specs:
- controller_spec.feature
- isolation_from_views.feature
@@ -15,12 +14,17 @@
- mailer_specs:
- url_helpers.feature
- routing_specs:
- - access_to_named_routes.feature
+ - route_to_matcher.feature
+ - be_routable_matcher.feature
+ - named_routes.feature
+- view_specs:
+ - view_spec.feature
+ - stub_template.feature
+ - inferred_controller_path.feature
- matchers:
- new_record_matcher.feature
- render_template_matcher.feature
- redirect_to_matcher.feature
- - be_routable_matcher.feature
- mocks:
- mock_model.feature
- stub_model.feature
View
10 features/Autotest.md
@@ -0,0 +1,10 @@
+The rspec:install generator creates a .rspec file, which tells RSpec to tell
+Autotest that you're using RSpec and Rails. You'll also need to add the ZenTest
+gem to your Gemfile:
+
+ gem "ZenTest"
+
+At this point, if all of the gems in your Gemfile are installed in system gems,
+you can just type autotest. If, however, Bundler is managing any gems for you
+directly (i.e. you've got :git or :path attributes in the Gemfile), you'll need
+to run bundle exec autotest.
View
8 features/Generators.md
@@ -0,0 +1,8 @@
+If you type script/rails generate, the only RSpec generator you'll actually see
+is rspec:install. That's because RSpec is registered with Rails as the test
+framework, so whenever you generate application components like models,
+controllers, etc, RSpec specs are generated instead of Test::Unit tests.
+
+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 the default scenario (ActiveRecord + Webrat).
View
25 features/README.markdown → features/README.md
@@ -36,30 +36,6 @@ Now you can run:
This adds the spec directory and some skeleton files, including a .rspec
file.
-## Generators
-
-If you type script/rails generate, the only RSpec generator you'll actually see
-is rspec:install. That's because RSpec is registered with Rails as the test
-framework, so whenever you generate application components like models,
-controllers, etc, RSpec specs are generated instead of Test::Unit tests.
-
-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 the default scenario (ActiveRecord + Webrat).
-
-## Autotest
-
-The rspec:install generator creates a .rspec file, which tells RSpec to tell
-Autotest that you're using RSpec and Rails. You'll also need to add the ZenTest
-gem to your Gemfile:
-
- gem "ZenTest"
-
-At this point, if all of the gems in your Gemfile are installed in system gems,
-you can just type autotest. If, however, Bundler is managing any gems for you
-directly (i.e. you've got :git or :path attributes in the Gemfile), you'll need
-to run bundle exec autotest.
-
## Webrat and Capybara
You can choose between webrat or capybara for simulating a browser, automating
@@ -80,4 +56,3 @@ 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).
-
View
56 features/Upgrade.md
@@ -0,0 +1,56 @@
+# 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 spec: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/core'
+
+ RSpec.configure do |config|
+ ...
+ end
+
+## Controller specs
+
+### `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-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
36 features/controller_specs/README.md
@@ -1,25 +1,29 @@
-A controller spec is an RSpec wrapper for a Rails functional test. It allows
-you to simulate a single http request in each example, and then specify
-expected outcomes, such as:
+A controller spec is an RSpec wrapper for a Rails functional test
+(ActionController::TestCase::Behavior). It allows you to simulate a single
+http request in each example, and then specify expected outcomes, including:
* templates that are rendered by the action
-* instance variables that are assigned in the controller to be shared with
- the view
+* instance variables that are assigned in the controller to be shared with the
+ view
* cookies that get 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)
-* rails assertions (assert_response 200)
+* standard rspec matchers (e.g. `response.code.should eq(200)`)
+* standard test/unit assertions (`assert_equal 200, response.code`)
+* 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)
+ * `response.should render_template (wraps assert_template)`
+ * `response.should redirect_to (wraps assert_redirected_to)`
+ * `assigns(:widget).should be_a_new(Widget)`
-Conventions:
+## Conventions:
-* pass the controller being spec'd to the describe method
- * this is only necessary for the outermost example group
-* by default, views are not rendered. See "isolation from views" and
- "render_views" for details
+* pass the controller being specified to the outermost `describe` method.
+
+ describe AccountController do
+ # ...
+
+* by default, views are not rendered. See
+ [views are stubbed by default](controller-specs/views-are-stubbed-by-default) and
+ [render_views](controller-specs/render-views) for details
View
11 features/controller_specs/isolation_from_views.feature
@@ -1,10 +1,11 @@
-Feature: do not render views
+Feature: views are stubbed by default
- By default, controller specs do not render views. This allows you specify
- which view template an action should try to render regardless of whether or
- not the template compiles cleanly.
+ By default, controller specs stub views with template that renders an empty
+ string instead of the views in the app. This allows you specify which view
+ template an action should try to render regardless of whether the template
+ compiles cleanly.
- NOTE: unlike rspec-rails-1.x, the template must exist.
+ NOTE: unlike rspec-rails-1.x, the real template must exist.
Scenario: expect template that is rendered by controller action (passes)
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
View
2  features/controller_specs/render_views.feature
@@ -1,4 +1,4 @@
-Feature: render views
+Feature: render_views
You can tell a controller example group to render views with the render_views
declaration.
View
6 features/helper_specs/helper_spec.feature
@@ -1,7 +1,7 @@
Feature: helper spec
- Helper specs live in spec/helpers. In order to access
- the helper methods you can call them on the "helper" object.
+ Helper specs live in `spec/helpers`. In order to access the helper methods
+ you can call them on the `helper` object.
Scenario: helper method that returns true
Given a file named "spec/helpers/application_helper_spec.rb" with:
@@ -50,4 +50,4 @@ Feature: helper spec
end
"""
When I run "rspec spec/helpers/application_helper_spec.rb"
- Then the output should contain "1 example, 0 failures"
+ Then the output should contain "1 example, 0 failures"
View
6 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
View
19 features/model_specs/README.md
@@ -0,0 +1,19 @@
+Model specs live in spec/models, e.g. spec/models/account_spec.rb. 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
View
3  features/model_specs/errors_on.feature
@@ -1,5 +1,8 @@
Feature: errors_on
+ rspec-rails adds an errors_on method to ActiveRecord objects to help you
+ specify validation errors.
+
Scenario: with one validation error
Given a file named "spec/models/widget_spec.rb" with:
"""
View
16 features/routing_specs/README.md
@@ -0,0 +1,16 @@
+Routing specs live in the `spec/routing` directory.
+
+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
View
36 ...ures/matchers/be_routable_matcher.feature → ...routing_specs/be_routable_matcher.feature
@@ -1,47 +1,47 @@
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"
+ 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"
+ Then the output should contain "1 example, 0 failures"
- 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
"""
@@ -54,7 +54,7 @@ Feature: be_routable matcher
"""
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
View
9 ...ting_specs/access_to_named_routes.feature → features/routing_specs/named_routes.feature
@@ -1,13 +1,16 @@
-Feature: access to named routes in routing specs
+Feature: named routes
- Scenario: access existing named route
+ 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")
+ {:get => new_widget_path}.
+ should route_to(:controller => "widgets", :action => "new")
end
end
"""
View
38 features/routing_specs/route_to_matcher.feature
@@ -0,0 +1,38 @@
+Feature: route_to matcher
+
+ The `route_to` matcher specifies that a request (verb + uri) is routable. It
+ is most valuable when specifying routes other than standard RESTful routes.
+
+ { :get => "/" }.should route_to(:controller => "welcome")
+
+ Scenario: passing route spec
+ 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 output should contain "1 example, 0 failures"
+
+ 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(:controller => "widgets", :action => "foo")
+ end
+ end
+ """
+
+ When I run "rspec spec/routing/widgets_routing_spec.rb"
+ Then the output should contain "1 example, 1 failure"
View
12 ...odel_specs/transactional_examples.feature → features/transactional_examples.feature
@@ -1,5 +1,17 @@
Feature: transactional examples
+ When you run the rspec:install generator, the generated spec/spec_helper.rb
+ configures rspec-rails to hook into the transaction management in Rails'
+ testing framework, which wraps every example in a transaction and rolls it
+ back after each example.
+
+ RSpec.configure do |config|
+ c.use_transactional_examples = true
+ end
+
+ This only works if you are using ActiveRecord as your ORM. If you are not, or
+ if you prefer to manage transactions differently, just delete that setting.
+
Scenario: run in transactions (default)
Given a file named "spec/models/widget_spec.rb" with:
"""
View
2  lib/rspec/rails/mocks.rb
@@ -101,7 +101,7 @@ def @object.instance_of?(other)
other == #{model_class}
end
def @object.respond_to?(method_name, include_private=false)
- #{model_class}.respond_to?(:column_names, include_private) && #{model_class}.column_names.include?(method_name.to_s) || super
+ #{model_class}.respond_to?(:column_names) && #{model_class}.column_names.include?(method_name.to_s) || super
end
def @object.class
#{model_class}
View
2  lib/rspec/rails/version.rb
@@ -1,7 +1,7 @@
module RSpec # :nodoc:
module Rails # :nodoc:
module Version # :nodoc:
- STRING = '2.3.0'
+ STRING = '2.3.1'
end
end
end

No commit comments for this range

Something went wrong with that request. Please try again.