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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090319/8b3b595c/attachment.html>
2009/3/19 Rick DeNatale <rick.denatale at 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 beYou *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-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/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.denatale at 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 > 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
2009/3/19 Rick DeNatale <rick.denatale at 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 at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley <sfeley at gmail.com> wrote:> 2009/3/19 Rick DeNatale <rick.denatale at 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> 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 at gmail.com) > ? ESCAPE POD - The Science Fiction Podcast Magazine > ? http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Thu, Mar 19, 2009 at 8:42 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Thu, Mar 19, 2009 at 10:20 PM, Stephen Eley <sfeley at gmail.com> wrote: >> 2009/3/19 Rick DeNatale <rick.denatale at 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_brilliantugh I think you''ve just reopened the debate over whether we ought to use should/is/must/etc :) That was fantastic Stephen, thanks!
Stephen Eley wrote:> 2009/3/19 Rick DeNatale <rick.denatale at 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? ..... >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!) > > > >
On Thu, Mar 19, 2009 at 11:42 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> > what_follows.should be_brilliantThank 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 at gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org
On Thu, Mar 19, 2009 at 11:20 PM, Stephen Eley <sfeley at gmail.com> wrote:> 2009/3/19 Rick DeNatale <rick.denatale at 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 interpretAlas, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090320/2472d354/attachment-0001.html>
Stephen Eley wrote:> 2009/3/19 Rick DeNatale <rick.denatale at 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!) >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/
On Fri, Mar 20, 2009 at 4:56 AM, Joseph Wilk <joe at josephwilk.net> wrote:> Stephen Eley wrote: >> >> 2009/3/19 Rick DeNatale <rick.denatale at 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? ?..... >> > > 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> > -- > 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!) >> >> >> >> > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >