Do not require exception messages to exactly match MRI #140

Merged
merged 1 commit into from Apr 21, 2012

2 participants

@jfirebaugh

Different Ruby implementations deserve latitude in the error messages, e.g.
to provide more precise diagnostics than MRI.

In particular, do not rely on the fact that RuntimeError generated by MRI
when calling bare raise without a current exception has an empty message.
That is not the case on Rubinius; it is arguably a bug in MRI.

Following this commit, all test pass on Rubinius head.

@jfirebaugh jfirebaugh Do not require exception messages to exactly match MRI
Different Ruby implementations deserve latitude in the error
messages, e.g. to provide more precise diagnostics than MRI.

In particular, do not rely on the fact that RuntimeError generated
by MRI when calling bare `raise` without a current exception has
an empty message. That is not the case on Rubinius; it is arguably
a bug in MRI.

Following this commit, all test pass on Rubinius head.
9fa523e
@dchelimsky dchelimsky closed this Apr 21, 2012
@dchelimsky dchelimsky reopened this Apr 21, 2012
@dchelimsky dchelimsky merged commit b98f0ba into rspec:master Apr 21, 2012
@dchelimsky dchelimsky added a commit that referenced this pull request Apr 21, 2012
@dchelimsky dchelimsky Fix potential false-positive so that it will fail correctly if there …
…is a regression.

- See #140.
694cbf1
@dchelimsky dchelimsky added a commit that referenced this pull request Apr 21, 2012
@dchelimsky dchelimsky Changlog for #140 780d4c2
@dchelimsky dchelimsky commented on the diff Apr 21, 2012
spec/rspec/matchers/have_spec.rb
@@ -386,7 +386,7 @@ def items
describe "have(n).things on an object which is not a collection nor contains one" do
it "fails" do
- lambda { Object.new.should have(2).things }.should raise_error(NoMethodError, /undefined method `things' for #<Object:/)
+ lambda { Object.new.should have(2).things }.should raise_error(NoMethodError) {|e| e.name == "things" }
@dchelimsky
RSpec member
dchelimsky added a line comment Apr 21, 2012

This one doesn't pass/fail correctly because the return value of the block is not evaluated for truth. If we change it to {|e| e.name.should eq "things"} it fails because the name is a symbol, so this should be {|e| e.name.should eq :things}, which I took care of in 694cbf1.

@jfirebaugh
jfirebaugh added a line comment Apr 21, 2012

Good catch, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment