[rspec-devel] [Rspec-users] subject.should_be true

aslak hellesoy aslak.hellesoy at gmail.com
Mon Oct 16 06:43:48 EDT 2006


On 10/16/06, David Lee <david at davelee.com.au> wrote:
> thanks, Aslak. I read it.
>
> I still think what i first did, which is that .should_be true should
> be more lax than should_equal true.
>

ri Object.==

-------------------------------------------------------------- Object#==
     obj == other        => true or false
     obj.equal?(other)   => true or false
     obj.eql?(other)     => true or false
------------------------------------------------------------------------
     Equality---At the +Object+ level, +==+ returns +true+ only if _obj_
     and _other_ are the same object. Typically, this method is
     overridden in descendent classes to provide class-specific meaning.

     Unlike +==+, the +equal?+ method should never be overridden by
     subclasses: it is used to determine object identity (that is,
     +a.equal?(b)+ iff +a+ is the same object as +b+).

     The +eql?+ method returns +true+ if _obj_ and _anObject_ have the
     same value. Used by +Hash+ to test members for equality. For
     objects of class +Object+, +eql?+ is synonymous with +==+.
     Subclasses normally continue this tradition, but there are
     exceptions. +Numeric+ types, for example, perform type conversion
     across +==+, but not across +eql?+, so:

        1 == 1.0     #=> true
        1.eql? 1.0   #=> false

So in Ruby, == is more lax than equal?
"2" == "2" #=> true - it's "lax"
"2".equal? "2" #=> false - it's "strict"

Currently in RSpec:
should_be uses Object.equal? - object identity.
should_equal uses Object.== - object "similarity"

In other words - currently in RSpec should_equal is more "lax" than should_be.

This is contrary to your recommendation.

What we *could* do is to change RSpec's implementation of should_be
and should_equal to:

should_equal uses Object.equal?
should_be uses Object.==

This would be more consistent from a Ruby pespective, but perhaps not
from an English perspective. Example: I'm more willing to say that two
dollar bills A and B are equal, but I wouldn't say that dolar bill A
*is* dollar bill B (A.should_be B). So in English things are a bit
different than in Ruby.

I think it boils down to: Do we want to be faithful to English or to
Ruby's definition of "equal" and the similar but very different
"is/be/==".

Aslak

> I'd expect
>
> 1.should_be true    # pass
> 1.should_equal true # fail
>
> the former being equivalent to assert; the latter to assert_equal
>
> cheers,
> David Lee
>
>
> On 16/10/2006, at 7:39 PM, aslak hellesoy wrote:
>
> > On 10/16/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> >> As things stand now, the following will all pass:
> >>
> >> true.should_be true
> >> "true".should_be true
> >> "false".should_be true
> >> 3.should_be true
> >> etc
> >>
> >> My feeling is that "should_be true" should only pass if it returns
> >> boolean true even though ruby says that non-nil/non-false is true.
> >>
> >
> > The old discussion about this topic is here:
> > http://rubyforge.org/pipermail/rspec-devel/2006-June/thread.html#228
> > (The "5.should.be true" thread)
> >
> > I recommend reading it.
> >
> >> Anybody else?
> >>
> >> David
> >> _______________________________________________
> >> Rspec-users mailing list
> >> Rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list