[rspec-devel] [ rspec-Feature Requests-14980 ] Nested Behaviour -- reopened

noreply at rubyforge.org noreply at rubyforge.org
Wed Oct 24 02:35:36 EDT 2007

Feature Requests item #14980, was opened at 2007-10-23 01:15
You can respond by visiting: 

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested Behaviour -- reopened

Initial Comment:
I'd like to reopen discussion for Nested Behaviour. On my current project, we are in a situation where nested describe blocks would be an elegant way to organize our examples.

It should be easy to implement given the current state of the source.
All that needs to be done is have Example.describe create a subclass of the current class.

Currently, here is our setup:

module AssociationMethods
  describe Person, "#games" do

module CustomMethods
  describe Person, "#current_game" do

Having nested describe blocks would allow:
describe Person, "association methods" do
  describe Person, "#games" do

describe Person, "custom methods" do
  describe Person, "#current_game" do

Also nested behaviour would allow sharing of before and after blocks.


>Comment By: Brian Takita (btakita)
Date: 2007-10-23 23:35

First, I'd like to frame this with the status of the current
There is an Example class. In rspec on rails, there is also
a RailsExample, ModelExample, ControllerExample,
ViewExample, and HelperExample.

before and after callbacks are registered on one of the
Example classes (aka Behaviours). When we get the callbacks
for a particular class, we also get the callbacks of the

For example, in a ModelExample before(:each), we get the
callbacks for:

For after(:all), the order is:

So there is a systematic way to get the before and after
callbacks based on inheritance.

I think the Example.behaviour method (nested behaviours)
would create a subclass of whatever class it is called from.
This would then use the existing before and after callback

So in reality, nesting describe blocks would be equivalent
to subclassing, which is something that rspec handles well
right now. I don't think it would be any more difficult to
debug than ordinary subclassing once the user knows that its
really inheritance being used.

I admit that this is probably an advanced feature. I propose
that we have a switch to turn it "on". The default will be
to not have this behaviour. If somebody wants to use it,
then they can call a method in Configuration.
This way, a fork will not be necessary.
I think that both the nested describes and the switch would
be simple to implement, since rspec is already architected
in the right way.


Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 06:59

... in fact, I'm so open that here is my proposal:

First let's close the loop on 1.1.0 issues and get that puppy out.

Once that's released, you should feel free to create a branch for this. It would be up to you to maintain it, keep it up to date w/ changes from trunk, etc. It would also be up to you to tend to questions on the mailing list related to this feature (and you can expect some from me as I'll be experimenting).

After some time, if people are using it and it is proving more beneficial than harmful, we can consider moving it into the trunk.

So a temporary fork of sorts. WDYT?


Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 06:33

Well, as you might imagine, I am very resistant to this. First, a few questions:

What would be the order of precedence of befores and afters?
What about a before(:all) or after(:all)?
How would they relate to the befores/afters set up globally?
What would the output look like?
Would the output be nested too? How deeply? Is there a limit?
Can we have examples inside the outer spec?
What is the scope of helper methods?
What happens with the --reverse flag.

I'm sure there are more of these questions that I'm not thinking of yet. I really think that this would open up a can of procedural worms that I'd be inclined to leave closed.

Additionally, even if all of my questions are answered easily, I can guarantee that it will lead to long debugging sessions focused on specs, which is exactly the opposite of where rspec should take you. I'd really hate to see the rspec lists get flooded with questions from people who are creating deeply nested hierarchies of specs and having trouble understanding why they aren't working. That's just not what this is all about.

My vote is nay.

But I'm open :)


You can respond by visiting: 

More information about the rspec-devel mailing list