[rspec-users] RSpec style and truthiness
Rick DeNatale
--
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
> 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"?
>
> --
> 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...@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
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
> 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
> 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
> 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
--
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
>
> 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
Nay frame, nor wall, yet viewable by all:
http://wiki.github.com/dchelimsky/rspec/should-be-should_not-be
Ben Mabey
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
2009/3/19 Rick DeNatale <rick.d...@gmail.com>:
> Even 'should be' is a bit grating. I'm tempted to write a pair of matchersshould be || should_not be: that is the expectation:
> like be_truthy and be_falsy, but I was wondering what other RSpec users have
> to say.
Whether 'tis nobler in the parser to interpret