Separate Cucumber step definitions and helpers so they can be shared
Add Cucumber setup for testing standalone Ruby applications
Fix WarningsSpy to capture more lines

If you had a bunch of lines that looked like this:

    /path/to/some/file:13:in `some_method': Some error (SomeException)
    Another line for the error
        /path/to/file1.rb:44:in `some_method'
        /path/to/file2.rb:29:in `some_other_method'

The first line would not be captured and re-send to standard out. This
commit fixes that.
Add minitest to Rails 3.x appraisals

The minitest dependency is necessary in order to write Cucumber tests
that depend on Minitest.
Fix delegate_method when used with shoulda-context

When specifying a custom subject, a straightforward usage of
`delegate_method`, such as the following

    class UserPresenter
      delegate :id, to: :user

      attr_reader :user

      def initialize(user)
        @user = user
      end
    end

    class UserPresenterTest < ActiveSupport::TestCase
      subject { UserPresenter.new(User.new) }
      should delegate_method(:id).to(:user)
    end

would error with something like:

    ArgumentError: wrong number of arguments (0 for 1)

This happens because the `should` method in shoulda-context asks the
DelegateMethodMatcher object for its description so that it can use it
to give the test a name and create a method that Test::Unit can run.
Now, the matcher's description needs a subject in order to determine
whether a class or an instance is being tested here -- if a class is
being tested the description will be "should delegate #id to \#user
object", if a class then "should delegate .id to .user object".
Unfortunately the matcher doesn't know what the subject is before
its #description method is called -- it only knows about this when it
gets evaluated.

Within the matcher we do have access to the current context class, so we
could read the subject block off of it and evaluate it. However, in
order to properly do this we also need access to the instance of the
test itself, which we do not have until the matcher is evaluated (by
which point it's too late).

Since there's really no way to solve this problem apart from rewriting a
lot of shoulda-context, and since often times your subject is an
instance and not a class, just assume it's an instance in this case.
Update NEWS for #591
Fix define_class/model to support namespaces

You can now say `define_class('Models::User')` and it will define a User
class inside of the Models module.

Similarly, you can also say `define_model('Models::User')` and it will
set the table name of the model to `models_users` instead of just
`users`.
Fix uniqueness matcher when scope is a *_type attr

Secondary author: Elliot Winkler <elliot.winkler@gmail.com>

This commit fixes `validate_uniqueness_of` when used with `scoped_to` so
that when one of the scope attributes is a polymorphic *_type attribute
and the model has another validation on the same attribute, the matcher
does not fail with an error.

As a part of the matching process, `validate_uniqueness_of` tries to
create two records that have the same values for each of the attributes
passed to `scoped_to`, except one of the attributes has a different
value. This way, the second record should be valid because it shouldn't
clash with the first one. It does this one attribute at a time.

Let's say the attribute in question is a polymorphic *_type attribute.
The value of this attribute is intended to be the name of a model as a
string. Let's assume the first record has a meaningful value for this
attribute already and we're trying to find a value for the second
record. In order to produce such a value, `validate_uniqueness_of`
generally calls #next (a common method in Ruby to generate a succeeding
version of an object sequentially) on the first object's corresponding
value. So in the case of a *_type attribute, since it's a string, it
would call #next on that string. For instance, "User" would become
"Uses".

You might have noticed a problem with this, which is "what if Uses is
not a valid model?" This is okay as long as there's nothing that is
trying to access the polymorphic association. Because as soon as this
happens, Rails will attempt to find a record using the polymorphic type
-- in other words, it will try to find the model that the *_type
attribute corresponds to. One of the ways this can happen is if the
*_type attribute in question has a validation on it itself.

Let's look at an example.

Given these models:

``` ruby
class User < ActiveRecord::Base
end

class Favorite < ActiveRecord::Base
  belongs_to :favoriteable, polymorphic: true
  validates :favoriteable, presence: true
  validates :favoriteable_id, uniqueness: { scope: [:favoriteable_type] }
end

FactoryGirl.define do
  factory :user

  factory :favorite do
    association :favoriteable, factory: :user
  end
end
```

and the following test:

``` ruby
require 'rails_helper'

describe Favorite do
  context 'validations' do
    before { FactoryGirl.create(:favorite) }
    it do
      should validate_uniqueness_of(:favoriteable_id).
        scoped_to(:favoriteable_type)
    end
  end
end
```

prior to this commit, the test would have failed with:

```
Failures:

  1) Favorite validations should require case sensitive unique value for favoriteable_id scoped to favoriteable_type
     Failure/Error: should validate_uniqueness_of(:favoriteable_id).
     NameError:
       uninitialized constant Uses
     # ./spec/models/favorite_spec.rb:6:in `block (3 levels) in <top (required)>'
```

Here, a Favorite record is created where `favoriteable_type` is set to
"Uses", and then validations are run on that record. The presence
validation on `favoriteable_type` is run which tries to access a "Uses"
model. But that model doesn't exist, so the test raises an error.

Now `validates_uniqueness_of` will set the *_type attribute to a
meaningful value. It still does this by calling #next on the first
record's value, but then it makes a new model that is simply an alias
for the original model. Hence, in our example, Uses would become a model
that is aliased to User.
Add NEWS for #592

[ci skip]
Improve failure message when `has_many` is missing

When test driving, writing an expectation such as

```ruby
it { should have_many(:children).through(:relationships).source(:child) }
```

used to provide the not-so-helpful error message

```
Failure/Error: it { should have_many(:children).through(:relationships).source(:child) }

     NoMethodError:

       undefined method `options' for nil:NilClass
```

The improved error message is

```
Expected Parent to have a has_many association called children (no association called children)
```
Fix 'delegate_method_matcher.rb' link in README.md

This is in accordance to commit #b695c2f97854767
fix typo in README
Make sure foreign keys can be specified as symbols for has_and_belongs_to_many associations.
Add `with_primary_key` to AssociationMatchers