I like to avoid over-constraining specifications, so for example of methods which return 'boolean' values, I prefer to test either truthiness (anything but false or nil), or falsiness (either false or nil). This isn't an issue true predicate methods which are of the right form to use be_whatever (as in a whatever? method taking no arguments). But for a method taking arguments this doesn't work (I think!), and even if it did I wouldn't want to use it for some cases. For instance I'm working with some code now (which I'm not really free to change) which has methods like has_member?(user) which tells whether or not the object has user as a member. So I tend to write things like
@it.has_member?(user).should be when the response is expected to be truthy or @it.has_member?(user).should_not be Now I recently noticed that if the second expectation fails, I get a rather snarky message like 'not only did it fail, but it's awkwardly expressed, try to express it as a positive.' While I agree that it isn't as elegant an expression as I like, I don't see a way out of the box to check that a result should be a falsy (or should that be non-truthy) value. Even 'should be' is a bit grating. I'm tempted to write a pair of matchers like be_truthy and be_falsy, but I was wondering what other RSpec users have to say. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
