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
2009/3/19 Rick DeNatale [email protected]:
@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”?
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:
super_spec.rb · GitHub
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 [email protected]:
On Thu, Mar 19, 2009 at 10:20 PM, Stephen E. [email protected] wrote:
2009/3/19 Rick DeNatale [email protected]:
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
2009/3/19 Rick DeNatale [email protected]:
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 E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
On Thu, Mar 19, 2009 at 8:42 PM, David C. [email protected]
wrote:
On Thu, Mar 19, 2009 at 10:20 PM, Stephen E. [email protected] wrote:
2009/3/19 Rick DeNatale [email protected]:
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!
Stephen E. 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 W.
On Thu, Mar 19, 2009 at 11:42 PM, David C. [email protected]
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 E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
On Fri, Mar 20, 2009 at 4:56 AM, Joseph W. [email protected] 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-should_not-be
Stephen E. 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
-
On Thu, Mar 19, 2009 at 11:20 PM, Stephen E. [email protected] wrote:
2009/3/19 Rick DeNatale [email protected]:
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