[#14980] Nested Example Groups -- reopened
Reported by Chad Humphries | November 19th, 2007 @ 06:37 AM | in 1.1.0
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
end
end
module CustomMethods
describe Person, "#current_game" do
end
end
Having nested describe blocks would allow:
describe Person, "association methods" do
describe Person, "#games" do
end
end
describe Person, "custom methods" do
describe Person, "#current_game" do
end
end
Also nested behaviour would allow sharing of before and after blocks.
Comments and changes to this ticket
-
Chad Humphries November 19th, 2007 @ 06:37 AM
Date: 2007-10-24 02:35
Sender: Brian Takita
First, I'd like to frame this with the status of the current
implementation:
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
superclasses.
For example, in a ModelExample before(:each), we get the
callbacks for:
Example.before(:each)
RailsExample.before(:each)
ModelExample.before(:each)
For after(:all), the order is:
ModelExample.before(:all)
RailsExample.before(:all)
Example.before(:all)
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
structure.
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.
Date: 2007-10-23 09:59
Sender: David Chelimsky
... 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?
Date: 2007-10-23 09:33
Sender: David Chelimsky
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 :)
-
David Chelimsky November 19th, 2007 @ 02:28 PM
- → State changed from “new” to “open”
- → Assigned user changed from “” to “Brian Takita”
-
David Chelimsky November 19th, 2007 @ 02:30 PM
- → Milestone changed from “” to “1.1.1”
-
David Chelimsky November 20th, 2007 @ 03:26 PM
- → Title changed from “[#14980] Nested Behaviour -- reopened” to “[#14980] Nested Example Groups -- reopened”
-
David Chelimsky November 21st, 2007 @ 03:37 PM
- → Milestone changed from “1.1.1” to “1.1.0”
Looks like we're going to have this for 1.1.0. It works now, but the output isn't quite right now - almost there.
-
David Chelimsky November 29th, 2007 @ 09:06 AM
- → State changed from “open” to “resolved”
Output works when using describe method. Not so for explicit subclasses of ExampleGroup. Closing this one, but http://rspec.lighthouseapp.com/p... is still open.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Behaviour Driven Development for Ruby.
Brian Takita