mirror of
https://github.com/thoughtbot/shoulda-matchers.git
synced 2022-11-09 12:01:38 -05:00
12543ede2e
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. |
||
---|---|---|
.. | ||
3.0.gemfile | ||
3.0.gemfile.lock | ||
3.1.gemfile | ||
3.1.gemfile.lock | ||
3.1_1.9.2.gemfile | ||
3.1_1.9.2.gemfile.lock | ||
3.2.gemfile | ||
3.2.gemfile.lock | ||
3.2_1.9.2.gemfile | ||
3.2_1.9.2.gemfile.lock | ||
4.0.0.gemfile | ||
4.0.0.gemfile.lock | ||
4.0.1.gemfile | ||
4.0.1.gemfile.lock | ||
4.1.gemfile | ||
4.1.gemfile.lock |