gem_repackager 0.1.0

data/support/gems/rspec-rails-2.11.0/features/Autotest.md

@@ -0,0 +1,24 @@
+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`.

data/support/gems/rspec-rails-2.11.0/features/Generators.md

@@ -0,0 +1,8 @@
+If you type script/rails generate, the only RSpec generator you'll actually see
+is rspec:install. That's because RSpec is registered with Rails as the test
+framework, so whenever you generate application components like models,
+controllers, etc, RSpec specs are generated instead of Test::Unit tests.
+
+Note that the generators are there to help you get started, but they are no
+substitute for writing your own examples, and they are only guaranteed to work
+out of the box for with Rails' defaults (ActiveRecord, no Capybara or Webrat).

data/support/gems/rspec-rails-2.11.0/features/GettingStarted.md

@@ -0,0 +1,84 @@
+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.

data/support/gems/rspec-rails-2.11.0/features/README.md

@@ -0,0 +1,56 @@
+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).

data/support/gems/rspec-rails-2.11.0/features/RailsVersions.md

@@ -0,0 +1,4 @@
+    rails version | rspec-rails version
+    2.3           | 1.3.4
+    3.0           | >= 2.0
+    3.1           | >= 2.6

data/support/gems/rspec-rails-2.11.0/features/Transactions.md

@@ -0,0 +1,84 @@
+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
+        @widget.should do_something
+      end
+        
+      it "does something else" do
+        @widget.should 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.

data/support/gems/rspec-rails-2.11.0/features/Upgrade.md

@@ -0,0 +1,117 @@
+# 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-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.

data/support/gems/rspec-rails-2.11.0/features/controller_specs/Cookies.md

@@ -0,0 +1,57 @@
+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.
+
+<pre>
+# spec
+request.cookies['foo'] = 'bar'
+get :some_action
+response.cookies['foo'].should eq('modified bar')
+
+# controller
+def some_action
+  cookies['foo'] = "modified #{cookies['foo']}"
+end
+</pre>
+
+#### 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.
+

data/support/gems/rspec-rails-2.11.0/features/controller_specs/README.md

@@ -0,0 +1,45 @@
+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 (`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)`
+    
+## Examples
+
+    describe TeamsController do
+      describe "GET index" do
+        it "assigns @teams" do
+          team = Team.create
+          get :index
+          assigns(:teams).should eq([team])
+        end
+
+        it "renders the index template" do
+          get :index
+          response.should 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.