Forum: RSpec RSpec style and truthiness

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-03-20 01:04
(Received via mailing list)
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
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2009-03-20 01:43
(Received via mailing list)
2009/3/19 Rick DeNatale <rick.denatale@gmail.com>:
>    @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"?
39100495c9937c39b2e0c704444e1b4a?d=identicon&s=25 Pat Maddox (Guest)
on 2009-03-20 02:05
(Received via mailing list)
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.denatale@gmail.com>:
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-20 04:39
(Received via mailing list)
2009/3/19 Rick DeNatale <rick.denatale@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 (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2009-03-20 04:46
(Received via mailing list)
On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley <sfeley@gmail.com> wrote:
> 2009/3/19 Rick DeNatale <rick.denatale@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
39100495c9937c39b2e0c704444e1b4a?d=identicon&s=25 Pat Maddox (Guest)
on 2009-03-20 08:19
(Received via mailing list)
On Thu, Mar 19, 2009 at 8:42 PM, David Chelimsky <dchelimsky@gmail.com>
wrote:
> On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley <sfeley@gmail.com> wrote:
>> 2009/3/19 Rick DeNatale <rick.denatale@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!
3c28deaff162aeda44f2e0bcdca1dacf?d=identicon&s=25 Joseph Wilk (josephwilk)
on 2009-03-20 11:19
(Received via mailing list)
Stephen Eley wrote:
> Or to inherit against a sea of matchers
> 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?  .....
>
Please frame that and put it on a wall somewhere. Its Quite brilliant.

--
Joseph Wilk
http://blog.josephwilk.net
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-20 15:50
(Received via mailing list)
On Thu, Mar 19, 2009 at 11:42 PM, David Chelimsky <dchelimsky@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?)


--
Have Fun,
   Steve Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2009-03-20 15:57
(Received via mailing list)
On Fri, Mar 20, 2009 at 4:56 AM, Joseph Wilk <joe@josephwilk.net> wrote:
>>>
>> To raise, perchance to rescue: ay, there's the rub,
>> With a bare assertion?  .....
>>
>
> Please frame that and put it on a wall somewhere. Its Quite brilliant.

Nay frame, nor wall, yet viewable by all:
http://wiki.github.com/dchelimsky/rspec/should-be-...
C694a032be7518a0d704318895f8fe1d?d=identicon&s=25 Ben Mabey (mabes)
on 2009-03-20 16:02
(Received via mailing list)
Stephen Eley wrote:
> Or to inherit against a sea of matchers
> For who would bear the Flogs and Heckles,
>  Simple is good, and there's a poetry about them.  Keep 'em!)
>

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-a...
8f6f95c4bd64d5f10dfddfdcd03c19d6?d=identicon&s=25 Rick Denatale (rdenatale)
on 2009-03-20 16:58
(Received via mailing list)
On Thu, Mar 19, 2009 at 11:20 PM, Stephen Eley <sfeley@gmail.com> wrote:

> 2009/3/19 Rick DeNatale <rick.denatale@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.


--
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
This topic is locked and can not be replied to.