Testing return value of a block argument


#1

Hi,

I’m using Log4r and one of its neat features is its handling of blocks
such that you can do:
log.debug { “Something bad happened” + some_expensive_method() }
instead of:
log.debug(“Something bad happened” + some_expensive_method())

The benefit of the former is that some_expensive_method() is not
executed until the debug() method executes so if your log level doesn’t
include DEBUG you don’t suffer the performance hit of calling
some_expensive_method() needlessly.

Is there any way to test what the resultant log message is from
evaluating the block?

i.e. something like:
log_mock.should_receive(:debug) { |log_block|
# execute log_block, and check its return value
}

I have a simple bit of code to tinker with: http://gist.github.com/79820

Thanks in advance,
yun


Yun Huang Y.
removed_email_address@domain.invalid …nom nom nom


#2

On Mon, Mar 16, 2009 at 7:00 AM, Yun Huang Y. removed_email_address@domain.invalid wrote:

you don’t suffer the performance hit of calling some_expensive_method()
I have a simple bit of code to tinker with: http://gist.github.com/79820

Thanks in advance,
yun

Hi Yun. Have a look at #and_yield , described at
http://rspec.info/documentation/mocks/message_expectations.html .

Cheers,
Nick


#3

On Mon, Mar 16, 2009 at 8:33 AM, Nick H. removed_email_address@domain.invalid
wrote:

http://rspec.info/documentation/mocks/message_expectations.html .
That was my first thought, but and_yield stubs what the method will
yield, not what it should yield. It’s like and_return.

///ark


#4

On 16 Mar 2009, at 11:00, Yun Huang Y. wrote:

I’m using Log4r

You might want to check out this library, which seems to be better
maintained these days:

http://github.com/TwP/logging/tree/master

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#5

On Mon, Mar 16, 2009 at 4:00 AM, Yun Huang Y. removed_email_address@domain.invalid wrote:

i.e. something like:
log_mock.should_receive(:debug) { |log_block|

execute log_block, and check its return value

}

I suppose you could always look at the source code for the debug
method, find out what it does with the result of the block and set an
expectation on that behavior.

///ark


#6

Going forward, what do people think about being able to say

mock.should_receive(:debug).with_block { |log_block|

execute log_block, and check its return value

}

Thoughts?

Peter


#7

On Sun, Mar 22, 2009 at 10:33 AM, Peter J. removed_email_address@domain.invalid
wrote:

Going forward, what do people think about being able to say

mock.should_receive(:debug).with_block { |log_block|

execute log_block, and check its return value

}

Thoughts?

I like the idea, but I don’t know how well it will play with other
sorts of expectations. We’d probably need to alias it with and_block
so you could say:

mock.should_receive(:message).with(:these, “args”).and_block {|block|
… }

Would you please file a feature request for this?

Thanks,
David


#8

I have this exact same problem. Anyone have a solution?

TIA,


Guilherme Machado C.
removed_email_address@domain.invalid


#9

On Mon, Mar 16, 2009 at 4:00 AM, Yun Huang Y. removed_email_address@domain.invalid wrote:

Is there any way to test what the resultant log message is from evaluating
the block?

i.e. something like:
log_mock.should_receive(:debug) { |log_block|

execute log_block, and check its return value

}

Sorry - I don’t quite understand. Do you want to test the logger debug
method’s behavior when you pass it a certain block, or do you want to
test what the block itself does? If the former, it seems to me that
you wouldn’t want to mock the logger object. If the latter, you can
just test the block directly.

///ark