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

myronmarston opened this Issue Sep 26, 2012 · 5 comments


None yet

3 participants


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


Definitely seems surprising to me.


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)


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?


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?


Fixed by 04eb38d

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