rspec users - Sep 2009 - describe block proc parameter as alternative to before blocks?

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.

It''s a nubile idea though. Thoughts?

On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherford at 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?

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.
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''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... at gmail.com>
wrote:
> On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf... at 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... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

My last reply seems to have been swallowed by the Ajax monster.

In brief, my suggestion is just for readability/maintenance. I feel
the describe/context and before blocks are the same thing put in two
places, one being documentation and the other implementation.
Splitting them up like this seems like asking for trouble.

That said, before blocks do achieve the same result, albeit somewhat
inside out, and if put just after the describe it''s clear what is
going on.

It''s fair enough (particularly at this stage of development) to say
that the onus should be on the spec author rather than the tools to
write legible specs.

Thanks for the reply
Cheers

Nick

On Sep 20, 9:56?pm, David Chelimsky <dchelim... at gmail.com>
wrote:
> On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf... at 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... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

Sorry for the double post. Seems I haven''t acquired the patience for
mailing lists yet :)

I had another idea which might scratch the itch, or might seem
horrible:

Take this example from some rails controller specs

describe SiteImagesController, request = "get :index" do
  context "As a visitor:" do
    before(:each) {stub_admin_check @controller, false}
    should_not_execute :index, request
  end

I was just looking at this and thought why not switch the string to
the context helper.

Something more like

context as_a_visitor do
  should_not_execute :index, request
end

where as_a_visitor handles the stubbing and returns the documentation
string?



On Sep 21, 2:50?am, nruth <nick.rutherf... at gmail.com>
wrote:
> My last reply seems to have been swallowed by the Ajax monster.
>
> In brief, my suggestion is just for readability/maintenance. I feel
> the describe/context and before blocks are the same thing put in two
> places, one being documentation and the other implementation.
> Splitting them up like this seems like asking for trouble.
>
> That said, before blocks do achieve the same result, albeit somewhat
> inside out, and if put just after the describe it''s clear what is
> going on.
>
> It''s fair enough (particularly at this stage of development) to
say
> that the onus should be on the spec author rather than the tools to
> write legible specs.
>
> Thanks for the reply
> Cheers
>
> Nick
>
> On Sep 20, 9:56?pm, David Chelimsky <dchelim... at gmail.com> wrote:
>
>
>
> > On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf... at
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... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

On Sun, Sep 20, 2009 at 8:34 PM, nruth <nick.rutherford at 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... at gmail.com> wrote:
>> On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf... at
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... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at 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)

On Mon, Sep 21, 2009 at 8:56 AM, nruth <nick.rutherford at gmail.com>
wrote:
> Sorry for the double post. Seems I haven''t acquired the patience
for
> mailing lists yet :)
>
> I had another idea which might scratch the itch, or might seem
> horrible:
>
> Take this example from some rails controller specs
>
> describe SiteImagesController, request = "get :index" do
> ?context "As a visitor:" do
> ? ?before(:each) {stub_admin_check @controller, false}
> ? ?should_not_execute :index, request
> ?end
>
> I was just looking at this and thought why not switch the string to
> the context helper.
>
> Something more like
>
> context as_a_visitor do
> ?should_not_execute :index, request
> end
>
> where as_a_visitor handles the stubbing and returns the documentation
> string?
I kind of partially responded to this in my other response. Sorry for
splitting these up..... If as_a_visitor is to return the documentation
string I think we''ve created a very unnatural thing (at least for me,
but maybe I''m conditioned), for the return value of a helper to be
used to describe an example or set of examples. This moves the real,
descriptive, meaningful description away from the examples themselves,
and hides them in this context helper method which may be defined in
the same file, or maybe its defined in another file. Instead of having
the most meaningful description with your examples you''ve got it
somewhere else, and now to understand the example with the most
clarity the author intended to give it, it needs to go search it out
somewhere else.

For me I put a lot of emphasis on readability of the specs, and not
just on the description''s readability (which is great, but its not the
only thing). At some point the implementation of the examples
including before/after blocks need to communicate a important part of
the story for an example in a coherent and readable manner. I rather
like having a before/after block within a context, even though it
takes up at most 2 additional lines (the before/do and the end),
because the meat of the before/after block should be code that helps a
reader of the spec more clearly understand what''s involved with these
examples with a low amount of effort (they shouldn''t need to go search
for helpers to understand intent). If we remove that from being close
to the examples it applies to then I think we would be creating a
separation between the spec some of its most useful parts.



>
>
>
> On Sep 21, 2:50?am, nruth <nick.rutherf... at gmail.com> wrote:
>> My last reply seems to have been swallowed by the Ajax monster.
>>
>> In brief, my suggestion is just for readability/maintenance. I feel
>> the describe/context and before blocks are the same thing put in two
>> places, one being documentation and the other implementation.
>> Splitting them up like this seems like asking for trouble.
>>
>> That said, before blocks do achieve the same result, albeit somewhat
>> inside out, and if put just after the describe it''s clear what
is
>> going on.
>>
>> It''s fair enough (particularly at this stage of development)
to say
>> that the onus should be on the spec author rather than the tools to
>> write legible specs.
>>
>> Thanks for the reply
>> Cheers
>>
>> Nick
>>
>> On Sep 20, 9:56?pm, David Chelimsky <dchelim... at gmail.com>
wrote:
>>
>>
>>
>> > On Sun, Sep 20, 2009 at 9:38 AM, nruth <nick.rutherf... at
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... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at 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)

On Sun, Sep 20, 2009 at 9:34 PM, nruth <nick.rutherford at gmail.com>
wrote:
>
> I think I wasn''t clear with my original post: before blocks work
fine,
> this is just a readability/comprehension/maintenance concern.
Peanut gallery: I personally find the separate "before" block clearer,
more readable, and more aesthetically appealing than an inline
":context => lambda {something}".

Lambda is an ugly word.  I know we inherited it from Lisp and that the
fundamental concept of closures is a beautiful thing, responsible for
puppies and rainbows and ActiveRecord, but still.  It doesn''t _feel_
good to have to add jargon on top of a block just to say "I know this
is a dynamic language, but this here?  This part is _really_ dynamic."
 Putting lambdas and Proc.news into my Ruby code always makes me feel
like I just scuffed my clean white shoes.  (The ''stabby''
operator in
Ruby 1.9 is only marginally better.)

Context?  "Context" isn''t an ugly word but it''s a
really ambiguous
one.  It means so many things, depending on...well, the context.

Whereas if I see a bunch of code with "before" or
"before(:each)" at
the top, I can make a _really_ good guess just from looking at it what
it''s supposed to do, and when.  It may not be attached umbilically to
the describe statement, but it''s still in there, doing what it does,
and I keep mine right underneath the describe where I can see it.

(I confess I''m not really sure what you mean by the before block
"going astray."  If you find that your test code is getting out from
under your fence at night, roaming the neighborhood, perhaps you
aren''t feeding it often enough?)



-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Sun, Sep 20, 2009 at 9:34 PM, nruth <nick.rutherford at gmail.com>
wrote:
>
> 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.
On further reading and thinking, I think I might see some of the
confusion.  You''re not quite correct that the describe and the before
are "separate blocks."  The before block lives *inside* the describe
block, and composes part of what is described.

The describe block is more than "documentation."  It''s a
class
definition.  (Literally.)  Class definitions do more than just provide
names; they bundle up behavior.  The before block can (not literally,
but effectively) be considered as a sort of constructor method for the
class, similar to ''def initialize'' in a non-RSpec class but
with more
chaining built in.  Nested example groups are subclasses that invoke
the superclasses''s constructors automatically, etc.

This is all very clean, mostly traditional object-oriented language
behavior.  Your suggestion of putting the initializer as a block value
to a hash option is more complicated; it''s like saying normal Ruby
classes should not have an ''initialize'' method, but instead
should be
declared like ''class Foo :constructor => lambda{initializer code
here}''.  Ruby''s insistence that you should call
''new'' but implement
''initialize'' is confusing enough.  The lambda-option style
doesn''t
make it clearer.

Does that make sense?  "Describe" and "before"
aren''t disconnected
entities.  They''re body and organ.  One is a part of the other.


-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

I agree that lambda''ing here would not help readability, I thought
that when I wrote it; it would quickly spiral out of control and make
things look horrible.

While I certainly appreciate the before / initialize parallel, I
hadn''t thought of it like that before. I don''t think about
ruby when
writing specs, I think about nesting concepts and readability (and
what I am making, ofc), that''s why I use rspec. Well, that and being
told to when I started :)

I write describe/context blocks to describe context, not to define
classes. That''s where I''m coming from when saying I want my
context
call and its setup to be on one line, rather than the setup being
portrayed as encapsulated by the concept rather than part of it.
Looking at it as a class definition is making this seem a lot less
weird now. I don''t know if that''s a good thing or not, but
thanks.

Before blocks are in common use and people know to look for them so
don''t introduce an alternative to confuse things -- yep, very valid
point.
I guess the short answer is no, stop being silly, this works well
within the language limitations, and the suggested alternative will
end up looking the same or worse.

Still, I found it interesting. Thanks for the feedback.

Running under the fence indeed, which hedge do these faults and
failures creep out from ;)

Nick

On Sep 22, 6:38?am, Stephen Eley <sfe... at gmail.com>
wrote:
> On Sun, Sep 20, 2009 at 9:34 PM, nruth <nick.rutherf... at gmail.com>
wrote:
>
> > 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.
>
> On further reading and thinking, I think I might see some of the
> confusion. ?You''re not quite correct that the describe and the
before
> are "separate blocks." ?The before block lives *inside* the
describe
> block, and composes part of what is described.
>
> The describe block is more than "documentation." ?It''s a
class
> definition. ?(Literally.) ?Class definitions do more than just provide
> names; they bundle up behavior. ?The before block can (not literally,
> but effectively) be considered as a sort of constructor method for the
> class, similar to ''def initialize'' in a non-RSpec class
but with more
> chaining built in. ?Nested example groups are subclasses that invoke
> the superclasses''s constructors automatically, etc.
>
> This is all very clean, mostly traditional object-oriented language
> behavior. ?Your suggestion of putting the initializer as a block value
> to a hash option is more complicated; it''s like saying normal Ruby
> classes should not have an ''initialize'' method, but
instead should be
> declared like ''class Foo :constructor => lambda{initializer
code
> here}''. ?Ruby''s insistence that you should call
''new'' but implement
> ''initialize'' is confusing enough. ?The lambda-option
style doesn''t
> make it clearer.
>
> Does that make sense? ?"Describe" and "before"
aren''t disconnected
> entities. ?They''re body and organ. ?One is a part of the other.
>
> --
> Have Fun,
> ? ?Steve Eley (sfe... at gmail.com)
> ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> ? ?http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

On Tue, Sep 22, 2009 at 8:55 AM, nruth <nick.rutherford at gmail.com>
wrote:
>
> I guess the short answer is no, stop being silly, [...]
It wasn''t silly at all to raise the question.  I apologize sincerely
if I gave the impression that I was trying to be insulting.  It''s
_very_ worthwhile to ask questions about The Way Things Are Done and
to discuss alternatives.  If we stop doing that, the culture
fossilizes.  And then it''s no fun any more.




-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Stephen

No worries, I didn''t get that impression. I was just gibing myself.

On the up side David''s plugin system sounds pretty nice, and I wonder
whether that will change the face of this at all.
It may enable myself or someone else to create some kind of context
spec chimera after all. :)

Cheers

Nick

On Sep 22, 2:52?pm, Stephen Eley <sfe... at gmail.com>
wrote:
> On Tue, Sep 22, 2009 at 8:55 AM, nruth <nick.rutherf... at gmail.com>
wrote:
>
> > I guess the short answer is no, stop being silly, [...]
>
> It wasn''t silly at all to raise the question. ?I apologize
sincerely
> if I gave the impression that I was trying to be insulting. ?It''s
> _very_ worthwhile to ask questions about The Way Things Are Done and
> to discuss alternatives. ?If we stop doing that, the culture
> fossilizes. ?And then it''s no fun any more.
>
> --
> Have Fun,
> ? ?Steve Eley (sfe... at gmail.com)
> ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> ? ?http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users