-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds strict option for string equality comparison #3709
Adds strict option for string equality comparison #3709
Conversation
@asterite This should fulfill both of our wants. It wont break any existing specs, and if you do want strict comparison, it is available. |
I think I would just change the default behaviour of String to strict comparison. One can always use Regex for inclusion. This simplifies the API a bit and shouldn't impact performance a lot (and if it does, well, it's used in the context of specs so super fast performance isn't needed there). The change will probably break all compiler specs which rely on the old behaviour, though, but maybe for now we can change the definition of |
(That is, I now agree with you about doing an equality check for strings) |
Or maybe add |
59186a3
to
b7a9c40
Compare
@asterite I added the strict equality checks and lots of test are failing now. So either:
I have no problem doing any of the 4 options. Let me know what you prefer. |
I like the default of fuzzily matching, I think just having the strict option is best. |
in master you can do expect_raises(MyError) {...}.message.should eq "my message" |
Closing in favour of the solution mentioned by @kostya above |
@spalladino Should we add that type of example to a doc somewhere so people know how to do a non-fuzzy check? |
@samueleaton good catch. I've opened #3909 since |
Just want to mention: expect_raises(MyError, "") {...} will pass when block raises "my_string".includes? "" #=> true
"".includes? "" #=> true Which is not really expected IMO. Maybe if we had decided to leave check by inclusion, we should have to handle this case differently : expect_raises(MyError, "") { raise MyError.new("O_o") } # => Expected MyError with "", got #<MyError: O_o> WDYT ? |
Solves #3707Doing:...will now do a strict comparison of messages instead ofex_to_s.includes?(msg)
Does strict string equality comparison for
expect_raises
spec messages.