[rspec-users] RSpec style and truthiness

3 views
Skip to first unread message

Rick DeNatale

unread,
Mar 19, 2009, 8:01:27 PM3/19/09
to rspec-users
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

David Chelimsky

unread,
Mar 19, 2009, 8:37:13 PM3/19/09
to rspec-users
2009/3/19 Rick DeNatale <rick.d...@gmail.com>:

> 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

You *can* actually say @it.should have_member(user) :)

> 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.'

Pardon the snarkiness (I wrote that) - that was intended for a
different situation (should_not be < 5, instead of should be >= 5),
and the fact that you're seeing it for just 'be' is a bug.

> 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.

I can't tell you why, but be_truthy sounds fine to me, but be_falsy
sounds awful.

How about "should be_truthy" or "should_not be_truthy"?

> _______________________________________________
> rspec-users mailing list
> rspec...@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Pat Maddox

unread,
Mar 19, 2009, 8:38:28 PM3/19/09
to rspec-users
I hate should/should_not be and so if I really *have* to do it then I
just throw a !! in the method and get back a real boolean. Not ideal,
but it works.

HOWEVER

Predicate matchers *do* accept args, and in the specific example you
gave, the have matcher comes to the rescue. Check out these examples:
http://gist.github.com/82148

The first one shows the typical be_blah form taking an arg, and the
second one shows some magic provided by the have matcher.

Pat


2009/3/19 Rick DeNatale <rick.d...@gmail.com>:

Stephen Eley

unread,
Mar 19, 2009, 11:20:07 PM3/19/09
to rspec-users
2009/3/19 Rick DeNatale <rick.d...@gmail.com>:

> 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.

should be || should_not be: that is the expectation:
Whether 'tis nobler in the parser to interpret
The outputs and side effects of outrageous duck typing,
Or to inherit against a sea of matchers
And by declaration extend them? To fail: to raise;
No more; and by a raise to say we throw
The exception and the thousand natural returns
The code is heir to, 'tis a specification
Devoutly to be wished. To fail: to raise;
To raise, perchance to rescue: ay, there's the rub,
For in that state of exception what tests may fail
When we have injected in this matcher code
Must give us pause: there's the RSpec
That makes calamity of such long backtraces;
For who would bear the Flogs and Heckles,
The oppressor's Reek, the proud man's Cucumber,
The pangs of despised Rcov, the spec_server's Drb,
The insolence of Autotest and the spurns
That patient merit of the occasional Rakes,
When he himself might his validation make
With a bare assertion? .....


(...And so forth. All of which is to say, before my Muse molested me,
that I rather _like_ the sparse "should be" and "should_not be" specs.
Simple is good, and there's a poetry about them. Keep 'em!)

--
Have Fun,
Steve Eley (sfe...@gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

David Chelimsky

unread,
Mar 19, 2009, 11:42:01 PM3/19/09
to rspec-users
On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley <sfe...@gmail.com> wrote:
> 2009/3/19 Rick DeNatale <rick.d...@gmail.com>:
>> 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.
>

what_follows.should be_brilliant

Pat Maddox

unread,
Mar 20, 2009, 2:49:50 AM3/20/09
to rspec-users
On Thu, Mar 19, 2009 at 8:42 PM, David Chelimsky <dchel...@gmail.com> wrote:
> On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley <sfe...@gmail.com> wrote:
>> 2009/3/19 Rick DeNatale <rick.d...@gmail.com>:
>>> 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.
>>
>
> what_follows.should be_brilliant

ugh I think you've just reopened the debate over whether we ought to
use should/is/must/etc

:)

That was fantastic Stephen, thanks!

Joseph Wilk

unread,
Mar 20, 2009, 5:56:51 AM3/20/09
to rspec-users
Please frame that and put it on a wall somewhere. Its Quite brilliant.

--
Joseph Wilk
http://blog.josephwilk.net

>
> (...And so forth. All of which is to say, before my Muse molested me,
> that I rather _like_ the sparse "should be" and "should_not be" specs.
> Simple is good, and there's a poetry about them. Keep 'em!)
>
>
>
>

_______________________________________________

Stephen Eley

unread,
Mar 20, 2009, 10:30:02 AM3/20/09
to rspec-users
On Thu, Mar 19, 2009 at 11:42 PM, David Chelimsky <dchel...@gmail.com> wrote:
>
> what_follows.should be_brilliant

Thank you! Glad I could provide a bit of entertainment.

(And hmmm. Now I'm wondering why Ruby culture doesn't have a
phenomenon like that of Perl culture, where hackers have 'Perl Poetry'
competitions with poems that actually compile and run. Wouldn't it be
easier to do in Ruby? Or is it because putting 'def' in front of all
methods makes it hard to write anything except outdated hip-hop?)

David Chelimsky

unread,
Mar 20, 2009, 10:45:47 AM3/20/09
to rspec-users

Nay frame, nor wall, yet viewable by all:
http://wiki.github.com/dchelimsky/rspec/should-be-should_not-be

Ben Mabey

unread,
Mar 20, 2009, 10:42:27 AM3/20/09
to rspec-users

That is just great. You have quite the talent. On another mailing list
we were talking about the standard story templates and it was suggested
that we write the stories in prose to make them more interesting to
read. Alistair Cockburn came up with this funny little limerick after
reading Liz Keogh's post about CAPTCHA[1]:

A spunky young buyer named Spry
Went online to buy something fly
But he found that a bot
Had taken his spot
Now he'll fill out a captcha and not cry

-Ben

1.
http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/

Rick DeNatale

unread,
Mar 20, 2009, 10:39:52 AM3/20/09
to rspec-users
On Thu, Mar 19, 2009 at 11:20 PM, Stephen Eley <sfe...@gmail.com> wrote:
2009/3/19 Rick DeNatale <rick.d...@gmail.com>:
> 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.

should be || should_not be: that is the expectation:
Whether 'tis nobler in the parser to interpret


Alas, poor Eley!  I knew him Chelmsky. 
Reply all
Reply to author
Forward
0 new messages