[rspec-users] [rspec] be_something accepts nils

Mark Wilden mark at mwilden.com
Fri Mar 13 10:23:06 EDT 2009


On Fri, Mar 13, 2009 at 5:17 AM, Ashley Moran >
> Just noticed that the behaviour of
>
>  @cow.should_not be_hungry
>
> is not the same as
>
>  @cow.hungry?.should == false # nil also passes
>
> Don't know how this has escaped me for so long =)
>
> What's the thinking behind this?  You can already do
>
>  @cow.hungry?.should(_not) be_nil
>
> so surely it makes more sense for be_true and be_false to check for
> booleans?

In common Ruby use, nil is usually treated the same as false, so
that's the way the dynamic matcher works - it's the most convenent.

You see explicit comparisons against true or false pretty rarely (in
my experience). Unless you have a specific need for a three-valued
truth system (e.g., true, false, and unknown), I think it's best
practice not to assume that if !x == true, then x must == false, and
vice versa.

///ark


More information about the rspec-users mailing list