Add warning about be_false being falsey in rspec 1.3

[krisleech]

No description provided.

[khiet]

💯 agree

[mottalrd]

Looks good 👍
I'll leave it open such that people will actually read it :)

[thejspr]

Nice gotcha

[dncrht]

Suggestion, for the end:
Rspec 1.3 only: For methods which return a boolean, e.g. active?, use be(false) or eq false…

[krisleech]

@dncrht Do you know if be and eq are aliases. I think be is an alias for ==, maybe all three are the same?

[krisleech]

For reference I also found a PR for the addition of be_falsey and change to be_false: rspec/rspec-expectations#283

[dncrht]

@krisleech nope:

a.should be(b) # passes if a.equal?(b)
a.should eq(b) # passes if a == b

Keeping this in mind:

a.equal?(b) # object identity - a and b refer to the same object
a.eql?(b) # object equivalence - a and b have the same value
a == b # object equivalence - a and b have the same value with type conversions

https://www.relishapp.com/rspec/rspec-expectations/v/2-0/docs/matchers/equality-matchers#compare-using-eq-(==)

Thanks for asking! (we all will learn something today)

[krisleech]

I didn't realise be was that strict. In our case be / equal? and eq / == will give the same result since there is only one false object AFAIK?

Do you think in this case we should just recommend one, either be(false) or eq(false) for consistency?

[dncrht]

same result since there is only one false object AFAIK?

Indeed

Do you think in this case we should just recommend one, either be(false) or eq(false) for consistency?

I'd say so, but I'm open to suggestions

[krisleech]

👍 I have no preference over be(false) or eq(false).

[dncrht]

+1 for eq false as is the common form in our new services

[krisleech]

Done 😄 Thanks @dncrht