Include matcher has puzzling behavior for hash entries with nil values #174

Closed
myronmarston opened this Issue Sep 26, 2012 · 5 comments

Projects

None yet

3 participants

Owner

This passes:

{}.should include('some_key' => nil)

While {}['some_key'] will return nil, I expected this to fail, because I was trying to specify that the hash had the key and the value was nil -- which is a very different thing from the hash not having the entry at all.

I can fix this pretty easily but I'm concerned about potential breakage it would cause.

/cc @dchelimsky @alindeman @patmaddox

Contributor

Definitely seems surprising to me.

Contributor

Is there a situation where this would be expected behavior? If not, I think it could be called a bug and therefore fixable in a minor release.

(Aside: I didn't even know the include matcher ever worked correctly on hashes before this)

Owner

The only risk of releasing this in a patch release is that it is a breaking change. The likelihood is that this is not going to affect anybody, but here's my thinking: let's risk it and release it in a patch release, but be prepared to quickly roll it back if it turns out to cause unresolvable trouble (i.e. it's in a 3rd party lib that and end user is using). WDYT?

Owner

I think we should change it, but do so in a minor release, not a patch release.

@samphippen -- you've been contributing to RSpec a lot recently...want to take a stab at this?

Owner

Fixed by 04eb38d

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