Permalink
Browse files

doc improvements

  • Loading branch information...
1 parent 7887b14 commit 20e1a6e67af06715a3f4d9f933fc11be885fbcc7 @dchelimsky dchelimsky committed Dec 26, 2010
View
@@ -1,4 +1,6 @@
- Upgrade.md
+- Generators.md
+- Autotest.md
- transactional_examples.feature
- model_specs:
- errors_on.feature
View
@@ -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
@@ -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
@@ -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).
-
@@ -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
@@ -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
@@ -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

0 comments on commit 20e1a6e

Please sign in to comment.