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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
