[rspec-users] [rspec-devel] underscores, sugar, and more and more bugs

Brian Takita brian.takita at gmail.com
Mon Nov 20 21:23:49 EST 2006


On 11/20/06, Brian Takita <brian.takita at gmail.com> wrote:
>
> On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> > I sent this earlier under with the subject "artificial sugar causes
> > cancer" and I think some spam filters ate it. Here it is again:
> > ======================================
> >
> > All,
> >
> > If you look at
> > http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
> > you'll see that Chad (the submitter) found the source of the bug.
> > Unfortunately, the source of *this* bug is the *solution* to a
> > *previous bug* in which Rails was replacing RSpec's method missing
> > with its own.
> >
> > When we settled on underscores, my one reservation was that we'd keep
> > running into this particular problem - RSpec's method_missing
> > conflicting with others.
> >
> > I have a proposition that preserves the underscore syntax, makes some
> > examples even more clear, and eliminates this problem once and for
> > all.
> >
> > 1. Eliminate reliance on method missing to handle expectations by
> > adding all of the documented should_x_y_z methods directly to Object.
> > These would all delegate off to Spec::Expectations::Should, ::Not,
> > ::Have, etc, so the design wouldn't change much and Object itself,
> > though bloated w/ methods, would not be bloated w/ implementation.
> >
> > This would also give us a single expectations module that we add to
> > Object, providing several benefits including:
> > # more clarity in the API
> > # a place to put meaningful rdoc
> > # a potential formal plugin point
> >
> > 2. Change should_be to ONLY handle arbitrary predicates (not serve as
> > an alias for should_equal):
> >
> > subject.should_be :empty => passes if subject.empty?
> > subject.should_be :instance_of, SomeClass => passes if
> > subject.instance_of? SomeClass
> > etc...
> >
> > In my opinion (feel free to disagree), this actually makes these
> > examples more readable. Consider these two:
> >
> > @bdd_framework.should_be_adopted_quickly #current
> > @bdd_framework.should_be :adopted_quickly #proposed
>
>
> I was looking through Dave Astel's Mastermind tutorial. In it he had the
> method win?
>   should_be :win
> seems clunky. I suppose that should_be supports past tense:
>   should_be :won
> and should supports present tense:
>   should :win
>
> Regarding the adopted_quickly example its:
>   should_be :adopted_quickly
> and
>   should :adopt_quickly
>

It also looks like should_be works with adjectives and past tense verbs with
adverbs.
  should be black?
  should be adopted quickly?

should seems to support using present tense verbs posed as a question.
  should adopt?

I apologize if this is old stuff that was already discussed.

I imagine that most of these boolean (?) methods are in present tense.
>
> In my view, these read equally well from a language perspective AND
> > they make it easier for a developer to mentally separate the
> > expectation (should_be) from the expected value (adopted_quickly?).
> >
> > This WOULD require changes to existing specs. I think for those of you
> > who don't wrap expectation args in parens that a trivial script would
> > handle this for you. If you do use parens, the script might be more
> > complex. Perhaps if we *do* choose this direction, one of you would
> > like to contribute such a script.
> >
> > I fully recognize that this would cause some pain, but it is my
> > feeling that not addressing this leaves us in a crippled position in
> > which we commit to being sidetracked by this issue constantly
> > returning instead of focusing on enhancing the API.
> >
> > I also think that this is a better option than any of the following
> > that also crossed my mind:
> > * revert to dots
> > * figure out a sexy way to intercept all attempts to rewrite method
> > missing and re-inject RSpec's method missing in its place (perhaps
> > this does sound sexy, but I doth believe that there is a venereal
> > disease hiding in its midst)
> > * leave things as they are and continue to add ugly hacks like
> > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
> > so call it that)
> > * hang myself from the nearest bridge
> >
> > Of course, if you have any solutions to propose, I'm all eyes.
> >
> > Thoughts?
> >
> > Thanks,
> > David
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/70ec1fa9/attachment.html 


More information about the rspec-users mailing list