On Sun, Sep 20, 2009 at 8:34 PM, nruth <nick.rutherf...@gmail.com> wrote:
> David
> Thanks for the reply.
>
> I think I wasn't clear with my original post: before blocks work fine,
> this is just a readability/comprehension/maintenance concern.
>
> We're using a describe (or context) block to name (or document) a
> state, then using a separate before block to set up that state
> (context). If that before block were to go astray the documentation
> would cease to be correct.
> It seems better to have this done in one place rather than two, as
> separate description statements and setup code could lead to confusion
> or errors through fragmented example groups.
>
> I'm not sure how helpful it would be if the setup takes more than half
> a line of code. Referencing a definition elsewhere wouldn't help
> readability, though would still make it clear that the describe was
> for that particular setup state.
>
> Before blocks do have the same effect, and if positioned sensibly
> should avoid these problems.
before blocks are also limited in where you can put them. They must be
specified very close the context in which they are to be applied. If
you provide a helper method as the context you create the need to
further separate an important part of an example from its context. I
also feel you lose a lot in what you describe and how you describe it
when you restrict it to ruby method names.
> It's not a big deal, and the onus should probably be on the spec
> author rather than the tools to produce clean and consistent specs?
I think it's important for people to pay attention when they write
code. Based on some of the code I've seen over the past few years I'm
not sure everyone would agree with me. :)
> I'm not surprised it's come up before, but I didn't find anything
> searching the group.
>
> Cheers
>
> Nick
>
> On Sep 20, 9:56 pm, David Chelimsky <dchelim...@gmail.com> wrote:
>> On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf...@gmail.com> wrote:
>> > I've been reading through the Rspec book to see if I missed any
>> > tricks, and the discussion of before block use for context setup in
>> > sec 12.6 struck me as interesting and something I had a knee-jerk
>> > reaction to.
>>
>> > I think that when you are using nested examples to describe a context
>> > change it is bad practice to allow any example within that group to
>> > run outside of that context. This could happen simply because you
>> > forgot to copy and paste (ouch) the setup code into your expectation.
>>
>> > before blocks solve this problem, but they are so tightly coupled to
>> > the describe call in this case, why not make them a describe method
>> > parameter? Ideally they would be the block passed to describe, but we
>> > can't do that since the example group is using that already.
>>
>> > So I would propose something like this sketch:
>>
>> > describe "a new capacity 10 stack", :context => lambda {...@stack =
>> > Stack.new(:capacity => 10)} do
>> > describe "with 4 pushed ints", :context => lambda { 4.times { @stack
>> > << rand(:int) } } do
>> > it "should allow push and return the new size" do
>> > �...@stack.push(rand(:int)).should == 5
>> > end
>> > end
>> > end
>>
>> > And the :context would just be executed as if it were a before block.
>>
>> > Of course you can arrange your specs so that the before block is
>> > directly after the describe, or similar, but this seems a nice
>> > alternative to me.
>>
>> The order of the before blocks, relative to the examples, is
>> irrelevant. An example group loads up all of its examples and before
>> and after blocks before anything is run. In other words, these two
>> will have the same effect:
>>
>> describe Thing do
>> before(:each) { @thing = Thing.new }
>> it "does something" do
>> @thing.should do_something
>> end
>> end
>>
>> describe Thing do
>> it "does something" do
>> @thing.should do_something
>> end
>> before(:each) { @thing = Thing.new }
>> end
>>
>> This is not the first time your idea has come up, and I've not
>> included it before because I want to avoid assigning specific meaning
>> to keys in the hash passed to describe(). rspec-2 will be using that
>> hash as part of a plugin API, so the more I can leave available, the
>> better. I'll be posting more about that soon, but first things first -
>> gotta get the book off to the printer :)
>>
>> Cheers,
>> David
>>
>>
>>
>> > It's a nubile idea though. Thoughts?
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
