rspec-rails-2.13.2/README_DEV.md 0000664 0000000 0000000 00000002364 12146042000 0015772 0 ustar 00root root 0000000 0000000 # Information for rspec-rails developers
rspec-rails lives in a complicated ecosystem. We need to run it against
multiple versions of rails and multiple versions of Ruby as well. There are
several tools already available to manage running against multiple versions of
Ruby (e.g. rvm), and there are even some multi-rails tools (e.g. multi-rails)
but we haven't found one that does exactly what we need here, so we've rolled
our own.
## The short version
gem install thor bundler
thor version:use 3.1.3
rake
## The long version
### thor version:use
The `thor version:use` task accepts any released version of rails, or either the
3-0-stable or master branches.
thor version:use master
thor version:use 3-0-stable
thor version:use 3-1-stable
thor version:use 3.1.3 # or any release >= 3.0.0
It then does a few things:
* generates a .rails-version file with the version listed. This is used
internally by assorted rake tasks.
* installs the bundle
* this includes binstubs, which are stored in ./bin
At any time, if you want to change rails versions, run `thor version:use` with
a new version number. To play it safe, you probably want to also run `rake
clobber` to delete all the code generated by the previous rails version.
rspec-rails-2.13.2/Rakefile 0000664 0000000 0000000 00000007066 12146042000 0015466 0 ustar 00root root 0000000 0000000 require "bundler"
begin
Bundler.setup
Bundler::GemHelper.install_tasks
rescue
raise "You need to install a bundle first. Try 'thor version:use 3.1.3'"
end
require 'yaml'
require 'rspec'
require 'rspec/core/rake_task'
require 'cucumber/rake/task'
desc "Run all examples"
RSpec::Core::RakeTask.new(:spec) do |t|
t.ruby_opts = %w[-w]
t.rspec_opts = %w[--color]
end
Cucumber::Rake::Task.new(:cucumber)
if RUBY_VERSION.to_f == 1.8
namespace :rcov do
task :clean do
rm_rf 'coverage.data'
end
desc "Run cucumber features using rcov"
Cucumber::Rake::Task.new :cucumber do |t|
t.cucumber_opts = %w{--format progress}
t.rcov = true
t.rcov_opts = %[-Ilib -Ispec --exclude "gems/*,features"]
t.rcov_opts << %[--text-report --sort coverage --aggregate coverage.data]
end
desc "Run all examples using rcov"
RSpec::Core::RakeTask.new :spec do |t|
t.rcov = true
t.rcov_opts = %[-Ilib -Ispec --exclude "gems/*,features"]
t.rcov_opts << %[--text-report --sort coverage --no-html --aggregate coverage.data]
end
end
task :rcov => ["rcov:clean", "rcov:spec", "rcov:cucumber"]
end
namespace :generate do
desc "generate a fresh app with rspec installed"
task :app do |t|
unless File.directory?('./tmp/example_app')
bindir = File.expand_path("bin")
# Rails 4 cannot use a `rails` binstub generated by Bundler
sh "rm -f #{bindir}/rails"
sh "bundle exec rails new ./tmp/example_app --skip-javascript --skip-sprockets --skip-gemfile --skip-git --skip-test-unit"
if test ?d, bindir
Dir.chdir("./tmp/example_app") do
Dir.mkdir("bin") unless File.directory?("bin")
sh "ln -sf #{bindir}/rake bin/rake"
sh "ln -sf #{bindir}/rspec bin/rspec"
sh "ln -sf #{bindir}/cucumber bin/cucumber"
application_file = File.read("config/application.rb")
sh "rm config/application.rb"
File.open("config/application.rb","w") do |f|
f.write application_file.gsub("config.assets.enabled = true","config.assets.enabled = false")
end
end
end
end
end
desc "generate a bunch of stuff with generators"
task :stuff do
in_example_app "bin/rake rails:template LOCATION='../../templates/generate_stuff.rb'"
end
end
def in_example_app(command)
Dir.chdir("./tmp/example_app/") do
Bundler.with_clean_env do
sh command
end
end
end
namespace :db do
task :migrate do
in_example_app "bin/rake db:migrate"
end
namespace :test do
task :prepare do
in_example_app "bin/rake db:test:prepare"
end
end
end
desc "run a variety of specs against the generated app"
task :smoke do
in_example_app "LOCATION='../../templates/run_specs.rb' bin/rake rails:template --backtrace"
end
desc 'clobber generated files'
task :clobber do
rm_rf "pkg"
rm_rf "tmp"
rm_rf "doc"
rm_rf ".yardoc"
end
namespace :clobber do
desc "clobber the generated app"
task :app do
rm_rf "tmp/example_app"
end
end
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 "cp Changelog.md features/"
if `relish versions rspec/rspec-rails`.split.map(&:strip).include? args[:version]
puts "Version #{args[:version]} already exists"
else
sh "relish versions:add rspec/rspec-rails:#{args[:version]}"
end
sh "relish push rspec/rspec-rails:#{args[:version]}"
sh "rm features/Changelog.md"
end
task :default => [:spec, "clobber:app", "generate:app", "generate:stuff", :smoke, :cucumber]
rspec-rails-2.13.2/Thorfile 0000664 0000000 0000000 00000000550 12146042000 0015507 0 ustar 00root root 0000000 0000000 class Version < Thor
desc "use VERSION", "installs the bundle the rails-VERSION"
def use(version)
`rm Gemfile.lock`
`echo #{version} > ./.rails-version`
"bundle install --binstubs".tap do |m|
say m
system m
end
end
desc "which", "print out the configured rails version"
def which
say `cat ./.rails-version`
end
end
rspec-rails-2.13.2/Upgrade.md 0000664 0000000 0000000 00000000030 12146042000 0015712 0 ustar 00root root 0000000 0000000 See features/Upgrade.md
rspec-rails-2.13.2/cucumber.yml 0000664 0000000 0000000 00000000236 12146042000 0016341 0 ustar 00root root 0000000 0000000 default: --require features --format progress --tags ~@wip
pretty: --require features --format pretty --tags ~@wip
wip: --require features --tags @wip
rspec-rails-2.13.2/features/ 0000775 0000000 0000000 00000000000 12146042000 0015626 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/.nav 0000664 0000000 0000000 00000001707 12146042000 0016420 0 ustar 00root root 0000000 0000000 - GettingStarted.md (Start from scratch)
- Generators.md (Generators)
- Transactions.md
- Autotest.md
- Changelog.md
- Upgrade.md
- RailsVersions.md (Rails versions)
- model_specs:
- errors_on.feature
- mocks:
- mock_model.feature
- stub_model.feature
- controller_specs:
- Cookies.md
- controller_spec.feature
- isolation_from_views.feature
- render_views.feature
- anonymous_controller.feature
- bypass_rescue.feature
- engine_routes.feature
- matchers:
- new_record_matcher.feature
- render_template_matcher.feature
- redirect_to_matcher.feature
- request_specs:
- request_spec.feature
- feature_specs:
- feature_spec.feature
- view_specs:
- view_spec.feature
- stub_template.feature
- inferred_controller_path.feature
- helper_specs:
- helper_spec.feature
- mailer_specs:
- url_helpers.feature
- routing_specs:
- route_to_matcher.feature
- be_routable_matcher.feature
- named_routes.feature
- engine_routes.feature
rspec-rails-2.13.2/features/Autotest.md 0000664 0000000 0000000 00000001420 12146042000 0017755 0 ustar 00root root 0000000 0000000 The `rspec:install` generator creates a `.rspec` file, which tells RSpec to
tell Autotest that you're using RSpec. You'll also need to add the ZenTest and
autotest-rails gems to your Gemfile:
gem "ZenTest", "~> 4.4.2"
gem "autotest-rails", "~> 4.1.0"
If all of the gems in your Gemfile are installed in system gems, you can just
type
autotest
If Bundler is managing any gems for you directly (i.e. you've got `:git` or
`:path` attributes in the Gemfile), however, you may need to run
bundle exec autotest
If you do, you require Autotest's bundler plugin in a `.autotest` file in the
project root directory or your home directory:
require "autotest/bundler"
Now you can just type `autotest`, it should prefix the generated shell command
with `bundle exec`.
rspec-rails-2.13.2/features/Generators.md 0000664 0000000 0000000 00000001030 12146042000 0020253 0 ustar 00root root 0000000 0000000 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 with Rails' defaults (ActiveRecord, no Capybara or Webrat).
rspec-rails-2.13.2/features/GettingStarted.md 0000664 0000000 0000000 00000004431 12146042000 0021102 0 ustar 00root root 0000000 0000000 Install Rails-3
$ gem install rails -v "~> 3.0.0"
### Generate an app
$ rails new example
$ cd example
### Add rspec-rails to the Gemfile
$ echo 'gem "rspec-rails", :group => [:development, :test]' >> Gemfile
### Install the bundle
$ bundle install
### Bootstrap RSpec
$ rails generate rspec:install
### Generate a scaffold
$ rails generate scaffold Widgets name:string
This generates files in the `app` and `spec` directories. The files in the
`app` directory are generated by Rails, and Rails delegates the generation of
the files in the `spec` directory to RSpec.
### Run migrations
$ rake db:migrate && rake db:test:prepare
### Run RSpec
$ rake spec
or
$ rspec spec --format documentation
If all went well, you should see output ending with:
29 examples, 0 failures, 2 pending
This output also includes the following controller spec:
WidgetsController
GET index
assigns all widgets as @widgets
GET show
assigns the requested widget as @widget
GET new
assigns a new widget as @widget
GET edit
assigns the requested widget as @widget
POST create
with valid params
creates a new Widget
assigns a newly created widget as @widget
redirects to the created widget
with invalid params
assigns a newly created but unsaved widget as @widget
re-renders the 'new' template
PUT update
with valid params
updates the requested widget
assigns the requested widget as @widget
redirects to the widget
with invalid params
assigns the widget as @widget
re-renders the 'edit' template
DELETE destroy
destroys the requested widget
redirects to the widgets list
Output like this can help to quickly gain a high level understanding of how an
object behaves. It also exposes which cases have been specified and which have
not. Note the balance between the examples for the `create` and `update`
actions. If the `redirects to the widget` example was missing from one or the
other, it would be easy to spot.
Take a look at the generated `spec/controllers/widgets_controller_spec.rb` to
get a sense of how to organize your specs to generate output like this.
rspec-rails-2.13.2/features/README.md 0000664 0000000 0000000 00000003032 12146042000 0017103 0 ustar 00root root 0000000 0000000 rspec-rails extends Rails' built-in testing framework to support rspec examples
for requests, controllers, models, views, helpers, mailers and routing.
## Rails-3
rspec-rails-2 supports rails-3.0.0 and later. For earlier versions of Rails,
you need [rspec-rails-1.3](http://rspec.info).
## Install
gem install rspec-rails
This installs the following gems:
rspec
rspec-core
rspec-expectations
rspec-mocks
rspec-rails
## Configure
Add rspec-rails to the :test and :development groups in the Gemfile:
group :test, :development do
gem "rspec-rails", "~> 2.4"
end
It needs to be in the :development group to expose generators and rake tasks
without having to type RAILS_ENV=test.
Now you can run:
script/rails generate rspec:install
This adds the spec directory and some skeleton files, including a .rspec
file.
## Webrat and Capybara
You can choose between webrat or capybara for simulating a browser, automating
a browser, or setting expectations using the matchers they supply. Just add
your preference to the Gemfile:
gem "webrat"
gem "capybara"
## Issues
The documentation for rspec-rails is a work in progress. We'll be adding
Cucumber features over time, and clarifying existing ones. If you have
specific features you'd like to see added, find the existing documentation
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).
rspec-rails-2.13.2/features/RailsVersions.md 0000664 0000000 0000000 00000000170 12146042000 0020751 0 ustar 00root root 0000000 0000000 rails version | rspec-rails version
2.3 | 1.3.4
3.0 | >= 2.0
3.1 | >= 2.6
rspec-rails-2.13.2/features/Transactions.md 0000664 0000000 0000000 00000005362 12146042000 0020626 0 ustar 00root root 0000000 0000000 When you run `rails generate rspec:install`, the `spec/spec_helper.rb` file
includes the following configuration:
RSpec.configure do |config|
config.use_transactional_fixtures = true
end
The name of this setting is a bit misleading. What it really means in Rails
is "run every test method within a transaction." In the context of rspec-rails,
it means "run every example within a transaction."
The idea is to start each example with a clean database, create whatever data
is necessary for that example, and then remove that data by simply rolling back
the transaction at the end of the example.
### Disabling transactions
If you prefer to manage the data yourself, or using another tool like
[database_cleaner](https://github.com/bmabey/database_cleaner) to do it for you,
simply tell RSpec to tell Rails not to manage transactions:
RSpec.configure do |config|
config.use_transactional_fixtures = false
end
### Data created in `before(:each)` are rolled back
Any data you create in a `before(:each)` hook will be rolled back at the end of
the example. This is a good thing because it means that each example is
isolated from state that would otherwise be left around by the examples that
already ran. For example:
describe Widget do
before(:each) do
@widget = Widget.create
end
it "does something" do
expect(@widget).to do_something
end
it "does something else" do
expect(@widget).to do_something_else
end
end
The `@widget` is recreated in each of the two examples above, so each example
has a different object, _and_ the underlying data is rolled back so the data
backing the `@widget` in each example is new.
### Data created in `before(:all)` are _not_ rolled back
`before(:all)` hooks are invoked before the transaction is opened. You can use
this to speed things up by creating data once before any example in a group is
run, however, this introduces a number of complications and you should only do
this if you have a firm grasp of the implications. Here are a couple of
guidelines:
1. Be sure to clean up any data in an `after(:all)` hook:
before(:all) do
@widget = Widget.create!
end
after(:all) do
@widget.destroy
end
If you don't do that, you'll leave data lying around that will eventually
interfere with other examples.
2. Reload the object in a `before(:each)` hook.
before(:all) do
@widget = Widget.create!
end
before(:each) do
@widget.reload
end
Even though database updates in each example will be rolled back, the
object won't _know_ about those rollbacks so the object and its backing
data can easily get out of sync.
rspec-rails-2.13.2/features/Upgrade.md 0000664 0000000 0000000 00000007456 12146042000 0017553 0 ustar 00root root 0000000 0000000 # 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 rspec: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/rails'
RSpec.configure do |config|
...
end
## Controller specs
### isolation from view templates
By default, controller specs do _not_ render view templates. This keeps
controller specs isolated from the content of views and their requirements.
NOTE that the template must exist, but it will not be rendered. This is
different from rspec-rails-1.x, in which the template didn't need to exist, but
ActionController makes a number of new decisions in Rails 3 based on the
existence of the template. To keep the RSpec code free of monkey patches, and
to keep the rspec user experience simpler, we decided that this would be a fair
trade-off.
### `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-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
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 specs
### `view.should render_template`
Rails changed the way it renders partials, so to set an expectation that a
partial gets rendered, you need
render
view.should render_template(:partial => "widget/_row")
### stub_template
Introduced in rspec-rails-2.2, simulates the presence of view templates on the
file system. This supports isolation from partials rendered by the vew template
that is the subject of a view example:
stub_template "widgets/_widget.html.erb" => "This Content"
### No more `have_tag` or `have_text`
Before Webrat came along, rspec-rails had its own `have_tag` and `have_text`
matchers that wrapped Rails' `assert_select`. Webrat included replacements for
these methods, as well as new matchers (`have_selector` and `have_xpath`), all
of which rely on Nokogiri to do its work, and are far less brittle than RSpec's
`have_tag`.
Capybara has similar matchers, which will soon be available view specs (they
are already available in controller specs with `render_views`).
Given the brittleness of RSpec's `have_tag` and `have_text` matchers and the
presence of new Webrat and Capybara matchers that do a better job, `have_tag`
and `have_text` were not included in rspec-rails-2.
## Mocks, stubs, doubles
### as_new_record
Earlier versions of the view generators generated stub_model with `:new_record?
=> true`. That is no longer recognized in rspec-rails-2, so you need to change
this:
stub_model(Widget, :new_record? => true)
to this:
stub_model(Widget).as_new_record
Generators in 2.0.0 final release will do the latter.
rspec-rails-2.13.2/features/controller_specs/ 0000775 0000000 0000000 00000000000 12146042000 0021206 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/controller_specs/Cookies.md 0000664 0000000 0000000 00000003523 12146042000 0023127 0 ustar 00root root 0000000 0000000 Controller specs wrap Rails controller tests, which expose a few different ways
to access cookies:
@request.cookies['key']
@response.cookies['key']
cookies['key']
rails-3.0.x and 3.1 handle these slightly differently, so to avoid confusion, we recommend
the following guidelines:
### Recommended guidelines for rails-3.0.0 to 3.1.0
* Access cookies through the `request` and `response` objects in the spec.
* Use `request.cookies` before the action to set up state.
* Use `response.cookies` after the action to specify outcomes.
* Use the `cookies` object in the controller action.
* Use String keys.
# spec
request.cookies['foo'] = 'bar'
get :some_action
expect(response.cookies['foo']).to eq('modified bar')
# controller
def some_action
cookies['foo'] = "modified #{cookies['foo']}"
end
#### Why use Strings instead of Symbols?
The `cookies` objects in the spec come from Rack, and do not support
indifferent access (i.e. `:foo` and `"foo"` are different keys). The `cookies`
object in the controller _does_ support indifferent access, which is a bit
confusing.
This changed in rails-3.1, so you _can_ use symbol keys, but we recommend
sticking with string keys for consistency.
#### Why not use the `cookies` method?
The `cookies` method combines the `request` and `response` cookies. This can
lead to confusion when setting cookies in the example in order to set up state
for the controller action.
# does not work in rails 3.0.0 > 3.1.0
cookies['foo'] = 'bar' # this is not visible in the controller
get :some_action
### Future versions of Rails
There is code in the master branch in rails that makes cookie access more
consistent so you can use the same `cookies` object before and after the action,
and you can use String or Symbol keys. We'll update these docs accordingly when
that is released.
rspec-rails-2.13.2/features/controller_specs/README.md 0000664 0000000 0000000 00000003001 12146042000 0022457 0 ustar 00root root 0000000 0000000 Controller specs live in `spec/controllers` or any example group with
`:type => :controller`.
A controller spec is an RSpec wrapper for a Rails functional test
([ActionController::TestCase::Behavior](https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/test_case.rb)).
It allows you to simulate a single http request in each example, and then
specify expected outcomes such as:
* rendered templates
* redirects
* instance variables assigned in the controller to be shared with the view
* cookies sent back with the response
To specify outcomes, you can use:
* 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:
* `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
describe "GET index" do
it "assigns @teams" do
team = Team.create
get :index
expect(assigns(:teams)).to eq([team])
end
it "renders the index template" do
get :index
expect(response).to render_template("index")
end
end
end
## Views
* 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.
rspec-rails-2.13.2/features/controller_specs/anonymous_controller.feature 0000664 0000000 0000000 00000023571 12146042000 0027066 0 ustar 00root root 0000000 0000000 Feature: anonymous controller
Use the `controller` method to define an anonymous controller derived from
`ApplicationController`. This is useful for specifying behavior like global
error handling.
To specify a different base class, you can pass the class explicitly to the
controller method:
controller(BaseController)
You can also configure RSpec to use the described class:
RSpec.configure do |c|
c.infer_base_class_for_anonymous_controllers = true
end
describe BaseController do
controller { ... }
# ^^ creates an anonymous subclass of `BaseController`
Scenario: specify error handling in ApplicationController
Given a file named "spec/controllers/application_controller_spec.rb" with:
"""ruby
require "spec_helper"
class ApplicationController < ActionController::Base
class AccessDenied < StandardError; end
rescue_from AccessDenied, :with => :access_denied
private
def access_denied
redirect_to "/401.html"
end
end
describe ApplicationController do
controller do
def index
raise ApplicationController::AccessDenied
end
end
describe "handling AccessDenied exceptions" do
it "redirects to the /401.html page" do
get :index
expect(response).to redirect_to("/401.html")
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: specify error handling in subclass of ApplicationController
Given a file named "spec/controllers/application_controller_subclass_spec.rb" with:
"""ruby
require "spec_helper"
class ApplicationController < ActionController::Base
class AccessDenied < StandardError; end
end
class ApplicationControllerSubclass < ApplicationController
rescue_from ApplicationController::AccessDenied, :with => :access_denied
private
def access_denied
redirect_to "/401.html"
end
end
describe ApplicationControllerSubclass do
controller(ApplicationControllerSubclass) do
def index
raise ApplicationController::AccessDenied
end
end
describe "handling AccessDenied exceptions" do
it "redirects to the /401.html page" do
get :index
expect(response).to redirect_to("/401.html")
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: infer base class from the described class
Given a file named "spec/controllers/base_class_can_be_inferred_spec.rb" with:
"""ruby
require "spec_helper"
RSpec.configure do |c|
c.infer_base_class_for_anonymous_controllers = true
end
class ApplicationController < ActionController::Base; end
class ApplicationControllerSubclass < ApplicationController; end
describe ApplicationControllerSubclass do
controller do
def index
render :text => "Hello World"
end
end
it "creates an anonymous controller derived from ApplicationControllerSubclass" do
expect(controller).to be_a_kind_of(ApplicationControllerSubclass)
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: invoke around filter in base class
Given a file named "spec/controllers/application_controller_around_filter_spec.rb" with:
"""ruby
require "spec_helper"
class ApplicationController < ActionController::Base
around_filter :an_around_filter
def an_around_filter
@callback_invoked = true
yield
end
end
describe ApplicationController do
controller do
def index
render :nothing => true
end
end
it "invokes the callback" do
get :index
expect(assigns[:callback_invoked]).to be_true
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: anonymous controllers only create resource routes
Given a file named "spec/controllers/application_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe ApplicationController do
controller do
def index
render :text => "index called"
end
def create
render :text => "create called"
end
def new
render :text => "new called"
end
def show
render :text => "show called"
end
def edit
render :text => "edit called"
end
def update
render :text => "update called"
end
def destroy
render :text => "destroy called"
end
def willerror
render :text => "will not render"
end
end
describe "#index" do
it "responds to GET" do
get :index
expect(response.body).to eq "index called"
end
it "also responds to POST" do
post :index
expect(response.body).to eq "index called"
end
it "also responds to PUT" do
put :index
expect(response.body).to eq "index called"
end
it "also responds to DELETE" do
delete :index
expect(response.body).to eq "index called"
end
end
describe "#create" do
it "responds to POST" do
post :create
expect(response.body).to eq "create called"
end
# And the rest...
%w{get post put delete}.each do |calltype|
it "responds to #{calltype}" do
send(calltype, :create)
expect(response.body).to eq "create called"
end
end
end
describe "#new" do
it "responds to GET" do
get :new
expect(response.body).to eq "new called"
end
# And the rest...
%w{get post put delete}.each do |calltype|
it "responds to #{calltype}" do
send(calltype, :new)
expect(response.body).to eq "new called"
end
end
end
describe "#edit" do
it "responds to GET" do
get :edit, :id => "anyid"
expect(response.body).to eq "edit called"
end
it "requires the :id parameter" do
expect { get :edit }.to raise_error(ActionController::RoutingError)
end
# And the rest...
%w{get post put delete}.each do |calltype|
it "responds to #{calltype}" do
send(calltype, :edit, {:id => "anyid"})
expect(response.body).to eq "edit called"
end
end
end
describe "#show" do
it "responds to GET" do
get :show, :id => "anyid"
expect(response.body).to eq "show called"
end
it "requires the :id parameter" do
expect { get :show }.to raise_error(ActionController::RoutingError)
end
# And the rest...
%w{get post put delete}.each do |calltype|
it "responds to #{calltype}" do
send(calltype, :show, {:id => "anyid"})
expect(response.body).to eq "show called"
end
end
end
describe "#update" do
it "responds to PUT" do
put :update, :id => "anyid"
expect(response.body).to eq "update called"
end
it "requires the :id parameter" do
expect { put :update }.to raise_error(ActionController::RoutingError)
end
# And the rest...
%w{get post put delete}.each do |calltype|
it "responds to #{calltype}" do
send(calltype, :update, {:id => "anyid"})
expect(response.body).to eq "update called"
end
end
end
describe "#destroy" do
it "responds to DELETE" do
delete :destroy, :id => "anyid"
expect(response.body).to eq "destroy called"
end
it "requires the :id parameter" do
expect { delete :destroy }.to raise_error(ActionController::RoutingError)
end
# And the rest...
%w{get post put delete}.each do |calltype|
it "responds to #{calltype}" do
send(calltype, :destroy, {:id => "anyid"})
expect(response.body).to eq "destroy called"
end
end
end
describe "#willerror" do
it "cannot be called" do
expect { get :willerror }.to raise_error(ActionController::RoutingError)
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: draw custom routes for anonymous controllers
Given a file named "spec/controllers/application_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe ApplicationController do
controller do
def custom
render :text => "custom called"
end
end
specify "a custom action can be requested if routes are drawn manually" do
routes.draw { get "custom" => "anonymous#custom" }
get :custom
expect(response.body).to eq "custom called"
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: refer to application routes in the controller under test
Given a file named "spec/controllers/application_controller_spec.rb" with:
"""ruby
require "spec_helper"
Rails.application.routes.draw do
match "/login" => "sessions#new", :as => "login", :via => "get"
end
describe ApplicationController do
controller do
def index
redirect_to login_url
end
end
it "redirects to the login page" do
get :index
expect(response).to redirect_to("/login")
end
end
"""
When I run `rspec spec`
Then the examples should all pass
rspec-rails-2.13.2/features/controller_specs/bypass_rescue.feature 0000664 0000000 0000000 00000004030 12146042000 0025427 0 ustar 00root root 0000000 0000000 Feature: bypass rescue
Use `bypass_rescue` to bypass both Rails' default handling of errors in
controller actions, and any custom handling declared with a `rescue_from`
statement.
This lets you specify details of the exception being raised, regardless of
how it might be handled upstream.
Background:
Given a file named "spec/controllers/gadgets_controller_spec_context.rb" with:
"""ruby
class AccessDenied < StandardError; end
class ApplicationController < ActionController::Base
rescue_from AccessDenied, :with => :access_denied
private
def access_denied
redirect_to "/401.html"
end
end
"""
Scenario: standard exception handling using `rescue_from`
Given a file named "spec/controllers/gadgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
require 'controllers/gadgets_controller_spec_context'
describe GadgetsController do
before do
def controller.index
raise AccessDenied
end
end
describe "index" do
it "redirects to the /401.html page" do
get :index
expect(response).to redirect_to("/401.html")
end
end
end
"""
When I run `rspec spec/controllers/gadgets_controller_spec.rb`
Then the examples should all pass
Scenario: bypass `rescue_from` handling with `bypass_rescue`
Given a file named "spec/controllers/gadgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
require 'controllers/gadgets_controller_spec_context'
describe GadgetsController do
before do
def controller.index
raise AccessDenied
end
end
describe "index" do
it "raises AccessDenied" do
bypass_rescue
expect { get :index }.to raise_error(AccessDenied)
end
end
end
"""
When I run `rspec spec/controllers/gadgets_controller_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/controller_specs/controller_spec.feature 0000664 0000000 0000000 00000002712 12146042000 0025762 0 ustar 00root root 0000000 0000000 Feature: controller spec
Scenario: simple passing example
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsController do
describe "GET index" do
it "has a 200 status code" do
get :index
expect(response.status).to eq(200)
end
end
end
"""
When I run `rspec spec`
Then the example should pass
Scenario: controller is exposed to global before hooks
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
RSpec.configure {|c| c.before { expect(controller).not_to be_nil }}
describe WidgetsController do
describe "GET index" do
it "doesn't matter" do
end
end
end
"""
When I run `rspec spec`
Then the example should pass
Scenario: controller is extended with a helper module
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
module MyHelper
def my_variable
end
end
RSpec.configure {|c| c.include MyHelper }
describe WidgetsController do
let(:my_variable) { 'is a value' }
describe 'something' do
specify { expect(my_variable).to eq 'is a value' }
end
end
"""
When I run `rspec spec`
Then the example should pass
rspec-rails-2.13.2/features/controller_specs/engine_routes.feature 0000664 0000000 0000000 00000002576 12146042000 0025443 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/controller_specs/isolation_from_views.feature 0000664 0000000 0000000 00000005616 12146042000 0027034 0 ustar 00root root 0000000 0000000 Feature: views are stubbed by default
By default, controller specs stub views with a 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 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:
"""ruby
require "spec_helper"
describe WidgetsController do
describe "index" do
it "renders the index template" do
get :index
expect(response).to render_template("index")
expect(response.body).to eq ""
end
it "renders the widgets/index template" do
get :index
expect(response).to render_template("widgets/index")
expect(response.body).to eq ""
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: expect template that is not rendered by controller action (fails)
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsController do
describe "index" do
it "renders the 'new' template" do
get :index
expect(response).to render_template("new")
end
end
end
"""
When I run `rspec spec`
Then the output should contain "1 example, 1 failure"
Scenario: expect empty templates to render when view path is changed at runtime (passes)
Given a file named "spec/controllers/things_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe ThingsController do
describe "custom_action" do
it "renders an empty custom_action template" do
controller.prepend_view_path 'app/views'
controller.append_view_path 'app/views'
get :custom_action
expect(response).to render_template("custom_action")
expect(response.body).to eq ""
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: expect template to render the real template with render_views when view path is changed at runtime
Given a file named "spec/controllers/things_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe ThingsController do
render_views
it "renders the real custom_action template" do
controller.prepend_view_path 'app/views'
get :custom_action
expect(response).to render_template("custom_action")
expect(response.body).to match(/template for a custom action/)
end
end
"""
When I run `rspec spec`
Then the examples should all pass
rspec-rails-2.13.2/features/controller_specs/render_views.feature 0000664 0000000 0000000 00000006222 12146042000 0025261 0 ustar 00root root 0000000 0000000 Feature: render_views
You can tell a controller example group to render views with the
`render_views` declaration in any individual group, or globally.
Scenario: render_views directly in a single group
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsController do
render_views
describe "GET index" do
it "says 'Listing widgets'" do
get :index
expect(response.body).to match /Listing widgets/m
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: render_views on and off in nested groups
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsController do
context "with render_views" do
render_views
describe "GET index" do
it "renders the actual template" do
get :index
expect(response.body).to match /Listing widgets/m
end
end
context "with render_views(false) nested in a group with render_views" do
render_views false
describe "GET index" do
it "renders the RSpec generated template" do
get :index
expect(response.body).to eq("")
end
end
end
end
context "without render_views" do
describe "GET index" do
it "renders the RSpec generated template" do
get :index
expect(response.body).to eq("")
end
end
end
context "with render_views again" do
render_views
describe "GET index" do
it "renders the actual template" do
get :index
expect(response.body).to match /Listing widgets/m
end
end
end
end
"""
When I run `rspec spec --order default --format documentation`
Then the output should contain:
"""ruby
WidgetsController
with render_views
GET index
renders the actual template
with render_views(false) nested in a group with render_views
GET index
renders the RSpec generated template
without render_views
GET index
renders the RSpec generated template
with render_views again
GET index
renders the actual template
"""
Scenario: render_views globally
Given a file named "spec/support/render_views.rb" with:
"""ruby
RSpec.configure do |config|
config.render_views
end
"""
And a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsController do
describe "GET index" do
it "renders the index template" do
get :index
expect(response.body).to match /Listing widgets/m
end
end
end
"""
When I run `rspec spec`
Then the examples should all pass
rspec-rails-2.13.2/features/feature_specs/ 0000775 0000000 0000000 00000000000 12146042000 0020456 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/feature_specs/feature_spec.feature 0000664 0000000 0000000 00000002553 12146042000 0024505 0 ustar 00root root 0000000 0000000 Feature: feature spec
Feature specs are high-level tests meant to exercise slices of functionality
through an application. They should drive the application only via its
external interface, usually web pages.
Feature specs require the [capybara](http://github.com/jnicklas/capybara)
gem, version 2.0.0 or later. Refer to the [capybara API
documentation](http://rubydoc.info/github/jnicklas/capybara/master) for more
information on the methods and matchers that can be used in feature specs.
The `feature` and `scenario` DSL correspond to `describe` and `it`,
respectively. These methods are simply aliases that allow feature specs to
read more as [customer tests](http://c2.com/cgi/wiki?CustomerTest) and
[acceptance tests](http://c2.com/cgi/wiki?AcceptanceTest).
Scenario: specify creating a Widget by driving the application with capybara
Given a file named "spec/features/widget_management_spec.rb" with:
"""ruby
require "spec_helper"
feature "Widget management" do
scenario "User creates a new widget" do
visit "/widgets/new"
fill_in "Name", :with => "My Widget"
click_button "Create Widget"
expect(page).to have_text("Widget was successfully created.")
end
end
"""
When I run `rspec spec/features/widget_management_spec.rb`
Then the example should pass
rspec-rails-2.13.2/features/helper_specs/ 0000775 0000000 0000000 00000000000 12146042000 0020302 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/helper_specs/helper_spec.feature 0000664 0000000 0000000 00000007103 12146042000 0024151 0 ustar 00root root 0000000 0000000 Feature: helper spec
Helper specs live in `spec/helpers`, or any example group with `:type =>
:helper`.
Helper specs expose a `helper` object, which includes the helper module being
specified, the `ApplicationHelper` module (if there is one) and all of the
helpers built into Rails. It does not include the other helper modules in
your app.
To access the helper methods you're specifying, simply call them directly
on the `helper` object.
NOTE: helper methods defined in controllers are not included.
Scenario: helper method that returns a value
Given a file named "spec/helpers/application_helper_spec.rb" with:
"""ruby
require "spec_helper"
describe ApplicationHelper do
describe "#page_title" do
it "returns the default title" do
expect(helper.page_title).to eq("RSpec is your friend")
end
end
end
"""
And a file named "app/helpers/application_helper.rb" with:
"""ruby
module ApplicationHelper
def page_title
"RSpec is your friend"
end
end
"""
When I run `rspec spec/helpers/application_helper_spec.rb`
Then the examples should all pass
Scenario: helper method that accesses an instance variable
Given a file named "spec/helpers/application_helper_spec.rb" with:
"""ruby
require "spec_helper"
describe ApplicationHelper do
describe "#page_title" do
it "returns the instance variable" do
assign(:title, "My Title")
expect(helper.page_title).to eql("My Title")
end
end
end
"""
And a file named "app/helpers/application_helper.rb" with:
"""ruby
module ApplicationHelper
def page_title
@title || nil
end
end
"""
When I run `rspec spec/helpers/application_helper_spec.rb`
Then the examples should all pass
Scenario: application helper is included in helper object
Given a file named "spec/helpers/widgets_helper_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsHelper do
describe "#widget_title" do
it "includes the app name" do
assign(:title, "This Widget")
expect(helper.widget_title).to eq("The App: This Widget")
end
end
end
"""
And a file named "app/helpers/application_helper.rb" with:
"""ruby
module ApplicationHelper
def app_name
"The App"
end
end
"""
And a file named "app/helpers/widgets_helper.rb" with:
"""ruby
module WidgetsHelper
def widget_title
"#{app_name}: #{@title}"
end
end
"""
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
rspec-rails-2.13.2/features/mailer_specs/ 0000775 0000000 0000000 00000000000 12146042000 0020274 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/mailer_specs/url_helpers.feature 0000664 0000000 0000000 00000002260 12146042000 0024175 0 ustar 00root root 0000000 0000000 Feature: URL helpers in mailer examples
Scenario: using URL helpers with default options
Given a file named "config/initializers/mailer_defaults.rb" with:
"""ruby
Rails.configuration.action_mailer.default_url_options = { :host => 'example.com' }
"""
And a file named "spec/mailers/notifications_spec.rb" with:
"""ruby
require 'spec_helper'
describe Notifications do
it 'should have access to URL helpers' do
expect { gadgets_url }.not_to raise_error
end
end
"""
When I run `rspec spec`
Then the examples should all pass
Scenario: using URL helpers without default options
Given a file named "config/initializers/mailer_defaults.rb" with:
"""ruby
# no default options
"""
And a file named "spec/mailers/notifications_spec.rb" with:
"""ruby
require 'spec_helper'
describe Notifications do
it 'should have access to URL helpers' do
expect { gadgets_url :host => 'example.com' }.not_to raise_error
expect { gadgets_url }.to raise_error
end
end
"""
When I run `rspec spec`
Then the examples should all pass
rspec-rails-2.13.2/features/matchers/ 0000775 0000000 0000000 00000000000 12146042000 0017434 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/matchers/README.md 0000664 0000000 0000000 00000000737 12146042000 0020722 0 ustar 00root root 0000000 0000000 rspec-rails offers a number of custom matchers, most of which are
rspec-compatible wrappers for Rails' assertions.
### redirects
# delegates to assert_redirected_to
expect(response).to redirect_to(path)
### templates
# delegates to assert_template
expect(response).to render_template(template_name)
### assigned objects
# passes if assigns(:widget) is an instance of Widget
# and it is not persisted
expect(assigns(:widget)).to be_a_new(Widget)
rspec-rails-2.13.2/features/matchers/new_record_matcher.feature 0000664 0000000 0000000 00000002206 12146042000 0024643 0 ustar 00root root 0000000 0000000 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 false to persisted?
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:
"""ruby
require "spec_helper"
describe Widget do
context "when initialized" do
subject(:widget) { Widget.new }
it "is a new widget" do
expect(widget).to be_a_new(Widget)
end
it "is not a new string" do
expect(widget).not_to be_a_new(String)
end
end
context "when saved" do
subject(:widget) { Widget.create }
it "is not a new widget" do
expect(widget).not_to be_a_new(Widget)
end
it "is not a new string" do
expect(widget).not_to be_a_new(String)
end
end
end
"""
When I run `rspec spec/models/widget_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/matchers/redirect_to_matcher.feature 0000664 0000000 0000000 00000002611 12146042000 0025017 0 ustar 00root root 0000000 0000000 Feature: redirect_to matcher
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).
Scenario: redirect_to with four possible options
Given a file named "spec/controllers/widgets_controller_spec.rb" with:
"""ruby
require "spec_helper"
describe WidgetsController do
describe "#create" do
subject { post :create, :widget => { :name => "Foo" } }
it "redirects to widget_url(@widget)" do
expect(subject).to redirect_to(widget_url(assigns(:widget)))
end
it "redirects_to :action => :show" do
expect(subject).to redirect_to :action => :show,
:id => assigns(:widget).id
end
it "redirects_to(@widget)" do
expect(subject).to redirect_to(assigns(:widget))
end
it "redirects_to /widgets/:id" do
expect(subject).to redirect_to("/widgets/#{assigns(:widget).id}")
end
end
end
"""
When I run `rspec spec/controllers/widgets_controller_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/matchers/relation_match_array.feature 0000664 0000000 0000000 00000001352 12146042000 0025201 0 ustar 00root root 0000000 0000000 Feature: ActiveRecord::Relation match array
The `match_array` matcher can be used with an `ActiveRecord::Relation`
(scope). The assertion will pass if the scope would return all of the
elements specified in the array on the right hand side.
Scenario: example spec with relation match_array matcher
Given a file named "spec/models/widget_spec.rb" with:
"""ruby
require "spec_helper"
describe Widget do
let!(:widgets) { Array.new(3) { Widget.create } }
subject { Widget.scoped }
it "returns all widgets in any order" do
expect(subject).to match_array(widgets)
end
end
"""
When I run `rspec spec/models/widget_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/matchers/render_template_matcher.feature 0000664 0000000 0000000 00000003152 12146042000 0025667 0 ustar 00root root 0000000 0000000 Feature: render_template matcher
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)
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:
"""ruby
require "spec_helper"
describe GadgetsController do
describe "GET #index" do
subject { get :index }
it "renders the index template" do
expect(subject).to render_template(:index)
expect(subject).to render_template("index")
expect(subject).to render_template("gadgets/index")
end
end
end
"""
When I run `rspec spec/controllers/gadgets_spec.rb`
Then the examples should all pass
Scenario: render_template in a view spec
Given a file named "spec/views/gadgets/index.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "gadgets/index" do
it "renders the index template" do
assign(:gadgets, [stub_model(Gadget)])
render
expect(view).to render_template(:index)
expect(view).to render_template("index")
expect(view).to render_template("gadgets/index")
end
end
"""
When I run `rspec spec/views`
Then the examples should all pass
rspec-rails-2.13.2/features/mocks/ 0000775 0000000 0000000 00000000000 12146042000 0016742 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/mocks/mock_model.feature 0000664 0000000 0000000 00000010721 12146042000 0022431 0 ustar 00root root 0000000 0000000 Feature: mock_model
The `mock_model` method generates a test double that acts like an instance of
`ActiveModel`. This is different from the `stub_model` method which generates
an instance of a real model class.
The benefit of `mock_model` over `stub_model` is that it is a true double, so
the examples are not dependent on the behavior (or mis-behavior), or even the
existence of any other code. If you're working on a controller spec and you
need a model that doesn't exist, you can pass `mock_model` a string and the
generated object will act as though its an instance of the class named by
that string.
Scenario: passing a string that represents a non-existent constant
Given a file named "spec/models/car_spec.rb" with:
"""ruby
require "spec_helper"
describe "mock_model('Car') with no Car constant in existence" do
it "generates a constant" do
expect(Object.const_defined?(:Car)).to be_false
mock_model("Car")
expect(Object.const_defined?(:Car)).to be_true
end
describe "generates an object that ..." do
it "returns the correct name" do
car = mock_model("Car")
expect(car.class.name).to eq("Car")
end
it "says it is a Car" do
car = mock_model("Car")
expect(car).to be_a(Car)
end
end
end
"""
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:
"""ruby
require "spec_helper"
describe Widget do
it "uses the existing constant" do
widget = mock_model("Widget")
expect(widget).to be_a(Widget)
end
end
"""
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:
"""ruby
require "spec_helper"
describe String do
it "raises" do
expect { mock_model(String) }.to raise_exception
end
end
"""
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:
"""ruby
require "spec_helper"
describe Widget do
let(:widget) { mock_model(Widget) }
it "is valid by default" do
expect(widget).to be_valid
end
it "is not a new record by default" do
expect(widget).not_to be_new_record
end
it "can be converted to a new record" do
expect(widget.as_new_record).to be_new_record
end
it "sets :id to nil upon destroy" do
widget.destroy
expect(widget.id).to be_nil
end
end
"""
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:
"""ruby
require "spec_helper"
describe "mock_model(Widget) with stubs" do
let(:widget) do
mock_model Widget, :foo => "bar",
:save => true,
:update_attributes => false
end
it "supports stubs for methods that don't exist in ActiveModel or ActiveRecord" do
expect(widget.foo).to eq("bar")
end
it "supports stubs for methods that do exist" do
expect(widget.save).to eq(true)
expect(widget.update_attributes).to be_false
end
describe "#errors" do
context "with update_attributes => false" do
it "is not empty" do
expect(widget.errors).not_to be_empty
end
end
end
end
"""
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:
"""ruby
require 'rspec/rails/mocks'
describe "Foo" do
it "is mockable" do
foo = mock_model("Foo")
expect(foo.id).to eq(1001)
expect(foo.to_param).to eq("1001")
end
end
"""
When I run `rspec mock_model_outside_rails_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/mocks/stub_model.feature 0000664 0000000 0000000 00000003314 12146042000 0022455 0 ustar 00root root 0000000 0000000 Feature: stub_model
The stub_model method generates an instance of a Active Model model.
While you can use stub_model in any example (model, view, controller,
helper), it is especially useful in view examples, which are inherently
more state-based than interaction-based.
Scenario: passing an Active Record constant with a hash of stubs
Given a file named "spec/models/widget_spec.rb" with:
"""ruby
require "spec_helper"
describe "stub_model(Widget) with a hash of stubs" do
let(:widget) do
stub_model Widget, :id => 5, :random_attribute => true
end
it "stubs :id" do
expect(widget.id).to eql(5)
end
it "stubs :random_attribute" do
expect(widget.random_attribute).to be_true
end
it "returns false for new_record? if :id is set" do
expect(widget).not_to be_new_record
end
it "can be converted to a new record" do
widget.as_new_record
expect(widget).to be_new_record
end
end
"""
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:
"""ruby
require "spec_helper"
describe "stub_model(Widget) with a block of stubs" do
let(:widget) do
stub_model Widget do |widget|
widget.id = 5
end
end
it "stubs :id" do
expect(widget.id).to eql(5)
end
end
"""
When I run `rspec spec/models/widget_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/model_specs/ 0000775 0000000 0000000 00000000000 12146042000 0020123 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/model_specs/README.md 0000664 0000000 0000000 00000001265 12146042000 0021406 0 ustar 00root root 0000000 0000000 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 chronologically" do
post = Post.create!
comment1 = post.comments.create!(:body => "first comment")
comment2 = post.comments.create!(:body => "second comment")
expect(post.reload.comments).to eq([comment2, comment1])
end
end
end
rspec-rails-2.13.2/features/model_specs/errors_on.feature 0000664 0000000 0000000 00000003540 12146042000 0023512 0 ustar 00root root 0000000 0000000 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 ::Rails::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
rspec-rails-2.13.2/features/model_specs/transactional_examples.feature 0000664 0000000 0000000 00000005314 12146042000 0026243 0 ustar 00root root 0000000 0000000 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 = "default"
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
rspec-rails-2.13.2/features/request_specs/ 0000775 0000000 0000000 00000000000 12146042000 0020513 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/request_specs/request_spec.feature 0000664 0000000 0000000 00000003271 12146042000 0024575 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/routing_specs/ 0000775 0000000 0000000 00000000000 12146042000 0020512 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/routing_specs/README.md 0000664 0000000 0000000 00000001150 12146042000 0021766 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/routing_specs/be_routable_matcher.feature 0000664 0000000 0000000 00000004712 12146042000 0026061 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/routing_specs/engine_routes.feature 0000664 0000000 0000000 00000001740 12146042000 0024737 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/routing_specs/named_routes.feature 0000664 0000000 0000000 00000000774 12146042000 0024564 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/routing_specs/route_to_matcher.feature 0000664 0000000 0000000 00000005366 12146042000 0025444 0 ustar 00root root 0000000 0000000 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
rspec-rails-2.13.2/features/step_definitions/ 0000775 0000000 0000000 00000000000 12146042000 0021174 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/step_definitions/additional_cli_steps.rb 0000664 0000000 0000000 00000000223 12146042000 0025673 0 ustar 00root root 0000000 0000000 Then /^the example(s)? should( all)? pass$/ do |_, _|
step %q{the output should contain "0 failures"}
step %q{the exit status should be 0}
end
rspec-rails-2.13.2/features/step_definitions/model_steps.rb 0000664 0000000 0000000 00000000116 12146042000 0024035 0 ustar 00root root 0000000 0000000 Given /a (\w+) model/ do |model_class_name|
puts eval(model_class_name)
end
rspec-rails-2.13.2/features/support/ 0000775 0000000 0000000 00000000000 12146042000 0017342 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/support/env.rb 0000664 0000000 0000000 00000002061 12146042000 0020456 0 ustar 00root root 0000000 0000000 require 'aruba/cucumber'
module ArubaExt
def run(cmd)
super(cmd =~ /^rspec/ ? "bin/#{cmd}" : cmd)
end
end
World(ArubaExt)
Before do
@aruba_timeout_seconds = 30
end
unless File.directory?('./tmp/example_app')
system "rake generate:app generate:stuff"
end
def aruba_path(file_or_dir)
File.expand_path("../../../#{file_or_dir.sub('example_app','aruba')}", __FILE__)
end
def example_app_path(file_or_dir)
File.expand_path("../../../#{file_or_dir}", __FILE__)
end
def write_symlink(file_or_dir)
source = example_app_path(file_or_dir)
target = aruba_path(file_or_dir)
system "ln -s #{source} #{target}"
end
def copy(file_or_dir)
source = example_app_path(file_or_dir)
target = aruba_path(file_or_dir)
system "cp -r #{source} #{target}"
end
Before do
steps %Q{
Given a directory named "spec"
}
Dir['tmp/example_app/*'].each do |file_or_dir|
if !(file_or_dir =~ /spec$/)
write_symlink(file_or_dir)
end
end
["spec/spec_helper.rb"].each do |file_or_dir|
write_symlink("tmp/example_app/#{file_or_dir}")
end
end
rspec-rails-2.13.2/features/support/rails_versions.rb 0000664 0000000 0000000 00000000212 12146042000 0022724 0 ustar 00root root 0000000 0000000 Around "@unsupported-on-rails-3-0" do |scenario, block|
require 'rails'
block.call unless ::Rails.version.to_s.start_with?("3.0")
end
rspec-rails-2.13.2/features/view_specs/ 0000775 0000000 0000000 00000000000 12146042000 0017775 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/features/view_specs/inferred_controller_path.feature 0000664 0000000 0000000 00000002464 12146042000 0026435 0 ustar 00root root 0000000 0000000 Feature: view spec infers controller path and action
Scenario: infer controller path
Given a file named "spec/views/widgets/new.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "widgets/new" do
it "infers the controller path" do
expect(controller.request.path_parameters[:controller]).to eq("widgets")
expect(controller.controller_path).to eq("widgets")
end
end
"""
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:
"""ruby
require "spec_helper"
describe "widgets/new" do
it "infers the controller path" do
expect(controller.request.path_parameters[:action]).to eq("new")
end
end
"""
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:
"""ruby
require "spec_helper"
describe "widgets/_form" do
it "includes a link to new" do
expect(controller.request.path_parameters[:action]).to be_nil
end
end
"""
When I run `rspec spec/views`
Then the examples should all pass
rspec-rails-2.13.2/features/view_specs/stub_template.feature 0000664 0000000 0000000 00000003152 12146042000 0024223 0 ustar 00root root 0000000 0000000 Feature: stub template
In order to isolate view specs from the partials rendered by the primary
view, rspec-rails (since 2.2) provides the stub_template method.
Scenario: stub template that does not exist
Given a file named "spec/views/gadgets/list.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "gadgets/list" do
it "renders the gadget partial for each gadget" do
assign(:gadgets, [
mock_model(Gadget, :id => 1, :name => "First"),
mock_model(Gadget, :id => 2, :name => "Second")
])
stub_template "gadgets/_gadget.html.erb" => "<%= gadget.name %>
"
render
expect(rendered).to match /First/
expect(rendered).to match /Second/
end
end
"""
And a file named "app/views/gadgets/list.html.erb" with:
"""
<%= render :partial => "gadget", :collection => @gadgets %>
"""
When I run `rspec spec/views/gadgets/list.html.erb_spec.rb`
Then the examples should all pass
Scenario: stub template that exists
Given a file named "spec/views/gadgets/edit.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "gadgets/edit" do
before(:each) do
@gadget = assign(:gadget, stub_model(Gadget))
end
it "renders the form partial" do
stub_template "gadgets/_form.html.erb" => "This content"
render
expect(rendered).to match /This content/
end
end
"""
When I run `rspec spec/views/gadgets/edit.html.erb_spec.rb`
Then the examples should all pass
rspec-rails-2.13.2/features/view_specs/view_spec.feature 0000664 0000000 0000000 00000013346 12146042000 0023345 0 ustar 00root root 0000000 0000000 Feature: view spec
View specs live in spec/views and render view templates in isolation.
Scenario: passing spec that renders the described view file
Given a file named "spec/views/widgets/index.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "widgets/index" do
it "displays all the widgets" do
assign(:widgets, [
stub_model(Widget, :name => "slicer"),
stub_model(Widget, :name => "dicer")
])
render
expect(rendered).to match /slicer/
expect(rendered).to match /dicer/
end
end
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing spec with before and nesting
Given a file named "spec/views/widgets/index.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "widgets/index" do
context "with 2 widgets" do
before(:each) do
assign(:widgets, [
stub_model(Widget, :name => "slicer"),
stub_model(Widget, :name => "dicer")
])
end
it "displays both widgets" do
render
expect(rendered).to match /slicer/
expect(rendered).to match /dicer/
end
end
end
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing spec with explicit template rendering
Given a file named "spec/views/widgets/widget.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "rendering the widget template" do
it "displays the widget" do
assign(:widget, stub_model(Widget, :name => "slicer"))
render :template => "widgets/widget.html.erb"
expect(rendered).to match /slicer/
end
end
"""
And a file named "app/views/widgets/widget.html.erb" with:
"""
<%= @widget.name %>
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing spec with a description that includes the format and handler
Given a file named "spec/views/widgets/widget.xml.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "widgets/widget.html.erb" do
it "renders the HTML template" do
render
expect(rendered).to match /HTML/
end
end
describe "widgets/widget.xml.erb" do
it "renders the XML template" do
render
expect(rendered).to match /XML/
end
end
"""
And a file named "app/views/widgets/widget.html.erb" with:
"""
HTML
"""
And a file named "app/views/widgets/widget.xml.erb" with:
"""
XML
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing spec with rendering of locals in a partial
Given a file named "spec/views/widgets/_widget.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "rendering locals in a partial" do
it "displays the widget" do
widget = stub_model(Widget, :name => "slicer")
render :partial => "widgets/widget.html.erb", :locals => {:widget => widget}
expect(rendered).to match /slicer/
end
end
"""
And a file named "app/views/widgets/_widget.html.erb" with:
"""
<%= widget.name %>
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing spec with rendering of locals in an implicit partial
Given a file named "spec/views/widgets/_widget.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "rendering locals in a partial" do
it "displays the widget" do
widget = stub_model(Widget, :name => "slicer")
render "widgets/widget", :widget => widget
expect(rendered).to match /slicer/
end
end
"""
And a file named "app/views/widgets/_widget.html.erb" with:
"""
<%= widget.name %>
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing spec with rendering of text
Given a file named "spec/views/widgets/direct.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "rendering text directly" do
it "displays the given text" do
render :text => "This is directly rendered"
expect(rendered).to match /directly rendered/
end
end
"""
When I run `rspec spec/views`
Then the examples should all pass
Scenario: passing view spec that stubs a helper method
Given a file named "app/views/secrets/index.html.erb" with:
"""
<%- if admin? %>
Secret admin area
<%- end %>
"""
And a file named "spec/views/secrets/index.html.erb_spec.rb" with:
"""ruby
require 'spec_helper'
describe 'secrets/index' do
before do
view.stub(:admin?).and_return(true)
end
it 'checks for admin access' do
render
expect(rendered).to match /Secret admin area/
end
end
"""
When I run `rspec spec/views/secrets`
Then the examples should all pass
Scenario: request.path_parameters should match Rails by using symbols for keys
Given a file named "spec/views/widgets/index.html.erb_spec.rb" with:
"""ruby
require "spec_helper"
describe "controller.request.path_parameters" do
it "matches the Rails environment by using symbols for keys" do
[:controller, :action].each { |k| expect(controller.request.path_parameters.keys).to include(k) }
end
end
"""
When I run `rspec spec/views`
Then the examples should all pass
rspec-rails-2.13.2/lib/ 0000775 0000000 0000000 00000000000 12146042000 0014556 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/autotest/ 0000775 0000000 0000000 00000000000 12146042000 0016426 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/autotest/rails_rspec2.rb 0000664 0000000 0000000 00000006103 12146042000 0021343 0 ustar 00root root 0000000 0000000 # (c) Copyright 2006 Nick Sieger
#
# Permission is hereby granted, free of charge, to any person
# obtaining a copy of this software and associated documentation files
# (the "Software"), to deal in the Software without restriction,
# including without limitation the rights to use, copy, modify, merge,
# publish, distribute, sublicense, and/or sell copies of the Software,
# and to permit persons to whom the Software is furnished to do so,
# subject to the following conditions:
#
# The above copyright notice and this permission notice shall be
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
$:.push(*Dir["vendor/rails/*/lib"])
require 'active_support/core_ext'
require 'autotest/rspec2'
class Autotest::RailsRspec2 < Autotest::Rspec2
def initialize
super
setup_rails_rspec2_mappings
end
def setup_rails_rspec2_mappings
%w{coverage/ db/ doc/ log/ public/ script/ tmp/ vendor/rails vendor/plugins vendor/gems}.each do |exception|
add_exception(/^([\.\/]*)?#{exception}/)
end
clear_mappings
add_mapping(%r%^(test|spec)/fixtures/(.*).yml$%) { |_, m|
["spec/models/#{m[2].singularize}_spec.rb"] + files_matching(%r%^spec\/views\/#{m[2]}/.*_spec\.rb$%)
}
add_mapping(%r%^spec/.*_spec\.rb$%) { |filename, _|
filename
}
add_mapping(%r%^app/models/(.*)\.rb$%) { |_, m|
["spec/models/#{m[1]}_spec.rb"]
}
add_mapping(%r%^app/views/(.*)$%) { |_, m|
files_matching %r%^spec/views/#{m[1]}_spec.rb$%
}
add_mapping(%r%^app/controllers/(.*)\.rb$%) { |_, m|
if m[1] == "application"
files_matching %r%^spec/controllers/.*_spec\.rb$%
else
["spec/controllers/#{m[1]}_spec.rb"]
end
}
add_mapping(%r%^app/helpers/(.*)_helper\.rb$%) { |_, m|
if m[1] == "application" then
files_matching(%r%^spec/(views|helpers)/.*_spec\.rb$%)
else
["spec/helpers/#{m[1]}_helper_spec.rb"] + files_matching(%r%^spec\/views\/#{m[1]}/.*_spec\.rb$%)
end
}
add_mapping(%r%^config/routes\.rb$%) {
files_matching %r%^spec/(controllers|routing|views|helpers)/.*_spec\.rb$%
}
add_mapping(%r%^config/database\.yml$%) { |_, m|
files_matching %r%^spec/models/.*_spec\.rb$%
}
add_mapping(%r%^(spec/(spec_helper|support/.*)|config/(boot|environment(s/test)?))\.rb$%) {
files_matching %r%^spec/(models|controllers|routing|views|helpers)/.*_spec\.rb$%
}
add_mapping(%r%^lib/(.*)\.rb$%) { |_, m|
["spec/lib/#{m[1]}_spec.rb"]
}
add_mapping(%r%^app/mailers/(.*)\.rb$%) { |_, m|
["spec/mailers/#{m[1]}_spec.rb"]
}
end
end
rspec-rails-2.13.2/lib/generators/ 0000775 0000000 0000000 00000000000 12146042000 0016727 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec.rb 0000664 0000000 0000000 00000001202 12146042000 0020363 0 ustar 00root root 0000000 0000000 require 'rails/generators/named_base'
module Rspec
module Generators
class Base < ::Rails::Generators::NamedBase
def self.source_root
@_rspec_source_root ||= File.expand_path(File.join(File.dirname(__FILE__), 'rspec', generator_name, 'templates'))
end
if ::Rails::VERSION::STRING < '3.1'
def module_namespacing
yield if block_given?
end
end
end
end
end
module Rails
module Generators
class GeneratedAttribute
def input_type
@input_type ||= if type == :text
"textarea"
else
"input"
end
end
end
end
end
rspec-rails-2.13.2/lib/generators/rspec/ 0000775 0000000 0000000 00000000000 12146042000 0020043 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec/controller/ 0000775 0000000 0000000 00000000000 12146042000 0022226 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec/controller/controller_generator.rb 0000664 0000000 0000000 00000002110 12146042000 0026776 0 ustar 00root root 0000000 0000000 require 'generators/rspec'
module Rspec
module Generators
class ControllerGenerator < Base
argument :actions, :type => :array, :default => [], :banner => "action action"
class_option :template_engine, :desc => "Template engine to generate view files"
class_option :controller_specs, :type => :boolean, :default => true
class_option :view_specs, :type => :boolean, :default => true
def generate_controller_spec
return unless options[:controller_specs]
template 'controller_spec.rb',
File.join('spec/controllers', class_path, "#{file_name}_controller_spec.rb")
end
def generate_view_specs
return if actions.empty?
return unless options[:view_specs] && options[:template_engine]
empty_directory File.join("spec", "views", file_path)
actions.each do |action|
@action = action
template 'view_spec.rb',
File.join("spec", "views", file_path, "#{@action}.html.#{options[:template_engine]}_spec.rb")
end
end
end
end
end
rspec-rails-2.13.2/lib/generators/rspec/controller/templates/ 0000775 0000000 0000000 00000000000 12146042000 0024224 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec/controller/templates/controller_spec.rb 0000664 0000000 0000000 00000000443 12146042000 0027747 0 ustar 00root root 0000000 0000000 require 'spec_helper'
<% module_namespacing do -%>
describe <%= class_name %>Controller do
<% for action in actions -%>
describe "GET '<%= action %>'" do
it "returns http success" do
get '<%= action %>'
response.should be_success
end
end
<% end -%>
end
<% end -%>
rspec-rails-2.13.2/lib/generators/rspec/controller/templates/view_spec.rb 0000664 0000000 0000000 00000000250 12146042000 0026532 0 ustar 00root root 0000000 0000000 require 'spec_helper'
describe "<%= file_name %>/<%= @action %>.html.<%= options[:template_engine] %>" do
pending "add some examples to (or delete) #{__FILE__}"
end
rspec-rails-2.13.2/lib/generators/rspec/helper/ 0000775 0000000 0000000 00000000000 12146042000 0021322 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec/helper/helper_generator.rb 0000664 0000000 0000000 00000000566 12146042000 0025203 0 ustar 00root root 0000000 0000000 require 'generators/rspec'
module Rspec
module Generators
class HelperGenerator < Base
class_option :helper_specs, :type => :boolean, :default => true
def generate_helper_spec
return unless options[:helper_specs]
template 'helper_spec.rb', File.join('spec/helpers', class_path, "#{file_name}_helper_spec.rb")
end
end
end
end
rspec-rails-2.13.2/lib/generators/rspec/helper/templates/ 0000775 0000000 0000000 00000000000 12146042000 0023320 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec/helper/templates/helper_spec.rb 0000664 0000000 0000000 00000000737 12146042000 0026145 0 ustar 00root root 0000000 0000000 require 'spec_helper'
# Specs in this file have access to a helper object that includes
# the <%= class_name %>Helper. For example:
#
# describe <%= class_name %>Helper do
# describe "string concat" do
# it "concats two strings with spaces" do
# helper.concat_strings("this","that").should == "this that"
# end
# end
# end
<% module_namespacing do -%>
describe <%= class_name %>Helper do
pending "add some examples to (or delete) #{__FILE__}"
end
<% end -%>
rspec-rails-2.13.2/lib/generators/rspec/install/ 0000775 0000000 0000000 00000000000 12146042000 0021511 5 ustar 00root root 0000000 0000000 rspec-rails-2.13.2/lib/generators/rspec/install/install_generator.rb 0000664 0000000 0000000 00000000666 12146042000 0025562 0 ustar 00root root 0000000 0000000 module Rspec
module Generators
class InstallGenerator < ::Rails::Generators::Base
desc <