should_yield (is it needed?)

[Martin Emde]

I have the code working for this but I wanted an opinion on making a patch.

I sometimes have the need to expect that a method will yield a block it's given. Usually this means something like this:

    yielded = false

    subject.method { yielded = true }

    yielded.should == true

which is a bit tedious and ugly. My solution might be just as ugly, but I wanted to get feedback because it saves that tedious code.

    subject.method(&should_yield)

I wrote a few methods, that when called, return an object with #to_proc that expects that the proc is called (or not called). I have the following forms available fairly simply:

    subject.method(&should_not_yield)

    subject.method(&should_yield_with(object))

    # Expects 3 yields, one with each argument

    [1,2,3].each(&should_yield_each(1,2,3))

 

I think this is a little cleaner and the code is very simple. I wanted to get an opinion on whether this is worth making into a patch.

Martin Emde
Tw: @martinemde

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Peter Jaros]

I happen to think that's brilliant.

Peter


On Fri, Nov 6, 2009 at 10:43 PM, Martin Emde <martin.emde@...> wrote:

> I have the code working for this but I wanted an opinion on making a patch.
> I sometimes have the need to expect that a method will yield a block it's
> given. Usually this means something like this:
>     yielded = false
>     subject.method { yielded = true }
>     yielded.should == true
> which is a bit tedious and ugly. My solution might be just as ugly, but I
> wanted to get feedback because it saves that tedious code.
>     subject.method(&should_yield)
> I wrote a few methods, that when called, return an object with #to_proc that
> expects that the proc is called (or not called). I have the following forms
> available fairly simply:
>     subject.method(&should_not_yield)
>     subject.method(&should_yield_with(object))
>     # Expects 3 yields, one with each argument
>     [1,2,3].each(&should_yield_each(1,2,3))
>
> I think this is a little cleaner and the code is very simple. I wanted to
> get an opinion on whether this is worth making into a patch.
> Martin Emde
> Tw: @martinemde
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel@...
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[David Chelimsky-2]

On Fri, Nov 6, 2009 at 10:43 PM, Martin Emde <martin.emde@...> wrote:

I have the code working for this but I wanted an opinion on making a patch.

I sometimes have the need to expect that a method will yield a block it's given. Usually this means something like this:

    yielded = false

    subject.method { yielded = true }

    yielded.should == true

which is a bit tedious and ugly. My solution might be just as ugly, but I wanted to get feedback because it saves that tedious code.

    subject.method(&should_yield)

I wrote a few methods, that when called, return an object with #to_proc that expects that the proc is called (or not called). I have the following forms available fairly simply:

    subject.method(&should_not_yield)

    subject.method(&should_yield_with(object))

    # Expects 3 yields, one with each argument

    [1,2,3].each(&should_yield_each(1,2,3))

 

I think this is a little cleaner and the code is very simple. I wanted to get an opinion on whether this is worth making into a patch.

Martin Emde
Tw: @martinemde

Generally this looks really nice, and I can see the use, but it's so different from everything else that I need to think about it a bit more. Have you played around w/ any other syntax options that would be more aligned w/ the "actual.should matcher" format? Something like:

[1,2,3].should yield_on(:each) ???

 

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel

[Martin Emde]

On Tue, Nov 10, 2009 at 5:00 PM, David Chelimsky <dchelimsky@...> wrote:

[1,2,3].should yield_on(:each) ???

This does follow rspec syntax more closely... Let's run through a few use cases I can imagine.

current_user.stub!(:admin?).and_return(true)

helper.should yield_on(:admin_only)

# helper.admin_only &should_yield

[1,2,3].should yield_on(:each).each_of(1,2,3)

# [1,2,3].each &should_yield_each(1,2,3)

h = { :a => 1, :b => 2 }

h.should yield_on(:each).each_of(*h.to_a)

h.each &should_yield_each(*h.to_a)

helper.should yield_on(:link_to_function, "link text").with(an_instance_of(JavaScriptHelper::JavaScriptBuilder))

#  helper.link_to_function "link text", &should_yield_with(an_instance_of(JavaScriptHelper::JavaScriptBuilder))

I think both are pretty clear until the last example when this part in my format:  "link text", &should_yield(...)   starts to confuse what's going on exactly. It very clearly breaks from rspec syntax in that example.

helper.link_to_functio("link text", &assert_yielded_block)

That actually makes a bit more sense since the intention is clear. I'm passing a block that asserts that it will be yielded. However, this isn't rspec at all written like that.

The yield_on format seems to specify "When I call this method on the receiver, I expect it to yield." This is very similar to user.should be_an_admin in that the actual method call is not being called on the receiver but passed into the matcher.

Is this something we'd like to add to rspec? If so, I'll work out a patch.

Martin

_______________________________________________
rspec-devel mailing list
rspec-devel@...
http://rubyforge.org/mailman/listinfo/rspec-devel