Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
GEM
|
|
|
|
remote: https://rubygems.org/
|
|
|
|
specs:
|
|
|
|
actionmailer (3.2.18)
|
|
|
|
actionpack (= 3.2.18)
|
|
|
|
mail (~> 2.5.4)
|
|
|
|
actionpack (3.2.18)
|
|
|
|
activemodel (= 3.2.18)
|
|
|
|
activesupport (= 3.2.18)
|
|
|
|
builder (~> 3.0.0)
|
|
|
|
erubis (~> 2.7.0)
|
|
|
|
journey (~> 1.0.4)
|
|
|
|
rack (~> 1.4.5)
|
|
|
|
rack-cache (~> 1.2)
|
|
|
|
rack-test (~> 0.6.1)
|
|
|
|
sprockets (~> 2.2.1)
|
|
|
|
activemodel (3.2.18)
|
|
|
|
activesupport (= 3.2.18)
|
|
|
|
builder (~> 3.0.0)
|
|
|
|
activerecord (3.2.18)
|
|
|
|
activemodel (= 3.2.18)
|
|
|
|
activesupport (= 3.2.18)
|
|
|
|
arel (~> 3.0.2)
|
|
|
|
tzinfo (~> 0.3.29)
|
|
|
|
activeresource (3.2.18)
|
|
|
|
activemodel (= 3.2.18)
|
|
|
|
activesupport (= 3.2.18)
|
|
|
|
activesupport (3.2.18)
|
|
|
|
i18n (~> 0.6, >= 0.6.4)
|
|
|
|
multi_json (~> 1.0)
|
2014-10-08 06:44:50 +00:00
|
|
|
ansi (1.4.3)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
appraisal (1.0.0)
|
|
|
|
bundler
|
|
|
|
rake
|
|
|
|
thor (>= 0.14.0)
|
|
|
|
arel (3.0.3)
|
2014-06-17 04:54:02 +00:00
|
|
|
aruba (0.6.0)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
childprocess (>= 0.3.6)
|
|
|
|
cucumber (>= 1.1.1)
|
|
|
|
rspec-expectations (>= 2.7.0)
|
|
|
|
bcrypt-ruby (3.0.1)
|
|
|
|
bourne (1.5.0)
|
|
|
|
mocha (>= 0.13.2, < 0.15)
|
|
|
|
builder (3.0.4)
|
|
|
|
childprocess (0.5.3)
|
|
|
|
ffi (~> 1.0, >= 1.0.11)
|
|
|
|
coderay (1.1.0)
|
|
|
|
coffee-rails (3.2.2)
|
|
|
|
coffee-script (>= 2.2.0)
|
|
|
|
railties (~> 3.2.0)
|
|
|
|
coffee-script (2.2.0)
|
|
|
|
coffee-script-source
|
|
|
|
execjs
|
|
|
|
coffee-script-source (1.7.0)
|
2014-06-17 04:54:02 +00:00
|
|
|
cucumber (1.3.16)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
builder (>= 2.1.2)
|
|
|
|
diff-lcs (>= 1.1.3)
|
|
|
|
gherkin (~> 2.12)
|
|
|
|
multi_json (>= 1.7.5, < 2.0)
|
|
|
|
multi_test (>= 0.1.1)
|
|
|
|
diff-lcs (1.2.5)
|
|
|
|
erubis (2.7.0)
|
|
|
|
execjs (2.2.0)
|
|
|
|
ffi (1.9.3)
|
|
|
|
gherkin (2.12.2)
|
|
|
|
multi_json (~> 1.3)
|
2014-10-08 06:44:50 +00:00
|
|
|
hashie (3.3.1)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
hike (1.2.3)
|
2014-06-17 04:54:02 +00:00
|
|
|
i18n (0.6.11)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
journey (1.0.4)
|
|
|
|
jquery-rails (3.1.0)
|
|
|
|
railties (>= 3.0, < 5.0)
|
|
|
|
thor (>= 0.14, < 2.0)
|
|
|
|
json (1.8.1)
|
|
|
|
mail (2.5.4)
|
|
|
|
mime-types (~> 1.16)
|
|
|
|
treetop (~> 1.4.8)
|
|
|
|
metaclass (0.0.4)
|
|
|
|
method_source (0.8.2)
|
|
|
|
mime-types (1.25.1)
|
2014-10-08 06:44:50 +00:00
|
|
|
minitest (4.7.5)
|
|
|
|
minitest-reporters (0.14.24)
|
|
|
|
ansi
|
|
|
|
builder
|
|
|
|
minitest (>= 2.12, < 5.0)
|
|
|
|
powerbar
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
mocha (0.14.0)
|
|
|
|
metaclass (~> 0.0.1)
|
|
|
|
multi_json (1.10.1)
|
|
|
|
multi_test (0.1.1)
|
|
|
|
polyglot (0.3.5)
|
|
|
|
posix-spawn (0.3.8)
|
2014-10-08 06:44:50 +00:00
|
|
|
powerbar (1.0.11)
|
|
|
|
ansi (~> 1.4.0)
|
|
|
|
hashie (>= 1.1.0)
|
2015-01-21 22:52:32 +00:00
|
|
|
pry (0.10.1)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
coderay (~> 1.1.0)
|
|
|
|
method_source (~> 0.8.1)
|
|
|
|
slop (~> 3.4)
|
2015-01-21 22:52:32 +00:00
|
|
|
pry-nav (0.2.4)
|
|
|
|
pry (>= 0.9.10, < 0.11.0)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
pygments.rb (0.6.0)
|
|
|
|
posix-spawn (~> 0.3.6)
|
|
|
|
yajl-ruby (~> 1.1.0)
|
|
|
|
rack (1.4.5)
|
|
|
|
rack-cache (1.2)
|
|
|
|
rack (>= 0.4)
|
|
|
|
rack-ssl (1.3.4)
|
|
|
|
rack
|
|
|
|
rack-test (0.6.2)
|
|
|
|
rack (>= 1.0)
|
|
|
|
rails (3.2.18)
|
|
|
|
actionmailer (= 3.2.18)
|
|
|
|
actionpack (= 3.2.18)
|
|
|
|
activerecord (= 3.2.18)
|
|
|
|
activeresource (= 3.2.18)
|
|
|
|
activesupport (= 3.2.18)
|
|
|
|
bundler (~> 1.0)
|
|
|
|
railties (= 3.2.18)
|
|
|
|
railties (3.2.18)
|
|
|
|
actionpack (= 3.2.18)
|
|
|
|
activesupport (= 3.2.18)
|
|
|
|
rack-ssl (~> 1.3.2)
|
|
|
|
rake (>= 0.8.7)
|
|
|
|
rdoc (~> 3.4)
|
|
|
|
thor (>= 0.14.6, < 2.0)
|
|
|
|
rake (10.3.2)
|
|
|
|
rdoc (3.12.2)
|
|
|
|
json (~> 1.4)
|
|
|
|
redcarpet (3.1.2)
|
|
|
|
rspec-collection_matchers (1.0.0)
|
|
|
|
rspec-expectations (>= 2.99.0.beta1)
|
2014-06-17 04:54:02 +00:00
|
|
|
rspec-core (2.99.1)
|
|
|
|
rspec-expectations (2.99.2)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
diff-lcs (>= 1.1.3, < 2.0)
|
2014-06-17 04:54:02 +00:00
|
|
|
rspec-mocks (2.99.2)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
rspec-rails (2.99.0)
|
|
|
|
actionpack (>= 3.0)
|
|
|
|
activemodel (>= 3.0)
|
|
|
|
activesupport (>= 3.0)
|
|
|
|
railties (>= 3.0)
|
|
|
|
rspec-collection_matchers
|
|
|
|
rspec-core (~> 2.99.0)
|
|
|
|
rspec-expectations (~> 2.99.0)
|
|
|
|
rspec-mocks (~> 2.99.0)
|
|
|
|
sass (3.3.8)
|
|
|
|
sass-rails (3.2.6)
|
|
|
|
railties (~> 3.2.0)
|
|
|
|
sass (>= 3.1.10)
|
|
|
|
tilt (~> 1.3)
|
|
|
|
shoulda-context (1.2.1)
|
2015-01-21 22:52:32 +00:00
|
|
|
slop (3.6.0)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
sprockets (2.2.2)
|
|
|
|
hike (~> 1.2)
|
|
|
|
multi_json (~> 1.0)
|
|
|
|
rack (~> 1.0)
|
|
|
|
tilt (~> 1.1, != 1.3.0)
|
|
|
|
sqlite3 (1.3.9)
|
|
|
|
strong_parameters (0.2.3)
|
|
|
|
actionpack (~> 3.0)
|
|
|
|
activemodel (~> 3.0)
|
|
|
|
activesupport (~> 3.0)
|
|
|
|
railties (~> 3.0)
|
|
|
|
thor (0.19.1)
|
|
|
|
tilt (1.4.1)
|
|
|
|
treetop (1.4.15)
|
|
|
|
polyglot
|
|
|
|
polyglot (>= 0.3.1)
|
|
|
|
tzinfo (0.3.39)
|
|
|
|
uglifier (2.5.1)
|
|
|
|
execjs (>= 0.3.0)
|
|
|
|
json (>= 1.8.0)
|
|
|
|
watchr (0.7)
|
|
|
|
yajl-ruby (1.1.0)
|
|
|
|
yard (0.8.7.4)
|
|
|
|
|
|
|
|
PLATFORMS
|
|
|
|
ruby
|
|
|
|
|
|
|
|
DEPENDENCIES
|
|
|
|
activerecord-jdbc-adapter
|
|
|
|
activerecord-jdbcsqlite3-adapter
|
2014-10-22 06:16:26 +00:00
|
|
|
appraisal (~> 1.0)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
aruba
|
|
|
|
bcrypt-ruby (~> 3.0.0)
|
|
|
|
bourne (~> 1.3)
|
|
|
|
bundler (~> 1.1)
|
|
|
|
coffee-rails (~> 3.2.1)
|
|
|
|
jdbc-sqlite3
|
|
|
|
jquery-rails
|
|
|
|
jruby-openssl
|
2014-10-08 06:44:50 +00:00
|
|
|
minitest (~> 4.0)
|
|
|
|
minitest-reporters
|
2015-01-21 22:52:32 +00:00
|
|
|
pry-nav
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
pygments.rb
|
|
|
|
rails (~> 3.2.13)
|
|
|
|
rake (>= 0.9.2)
|
|
|
|
redcarpet
|
2014-06-17 04:54:02 +00:00
|
|
|
rspec-rails (= 2.99.0)
|
Use same assertion class as Rails, if loaded
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
2014-06-22 03:24:22 +00:00
|
|
|
sass-rails (~> 3.2.3)
|
|
|
|
shoulda-context (~> 1.2.0)
|
|
|
|
sqlite3
|
|
|
|
strong_parameters
|
|
|
|
therubyrhino
|
|
|
|
uglifier (>= 1.0.3)
|
|
|
|
watchr
|
|
|
|
yard
|