On 8 Aug 2010, at 12:05, Matt Wynne wrote:
>> And you override it using let(:foo), which would be a perfectly reasonable
>> way to handle it. In fact, it would be the way I would handle in
>> instinctively, because now I don't have to wrote my own memoization handling
>> into the method.
>
> I instinctively agree with ashley, but I see your point too David.
>
> Would it be awful to make let even more magic, and do something with #caller
> to forward the message to MiniTest if it didn't come from the code in your
> example block? Maybe the method defined by let could even have a __hidden
> name, and then RSpec can forward the message to that __hidden method if the
> message was sent from within the example block.
>
> Sounds pretty horrible, doesn't it?
Hmmm, sounds like it could create a pretty nasty coupling to MiniTest. Maybe
there's a general solution like:
define_example_method do # or maybe "define_helper" ?
# some stuff that only gets called from examples
end
I'm not sure I'd be keen on let embedding this magic, but maybe as a general
concept it makes more sense, as a way of isolating helper code in example
groups.
There's another side to the debate, which is that in shared example groups, I
prefer the precondition-check style to the templatemethod-fail style, ie rather
than:
def foo
raise "you need to define a foo method ..."
end
I'd prefer to write:
unless respond_to?(:foo)
raise "you need to define a foo method ..."
end
But that would involve evaluating the configuration block first >:)
Ash
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
