Feature Requests item #10781, was opened at 2007-05-11 10:17
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797
Category: reports
Group: None
Status: Open
Priority: 3
Submitted By: Greg Spurrier (gregspurrier)
Assigned to: Nobody (None)
Summary: Hierarchical specdoc output for shared behaviors
Initial Comment:
When shared behaviors are included into a behavior, there is no indication of the source of the behavior in the specdoc output. This can be confusing when multiple shared behaviors are included and have similar examples. E.g.:
describe "REST index action", :shared => true do
it "should return status code 200" do
end
end
describe "REST show action", :shared => true do
it "should return status code 200" do
end
end
describe "FooController" do
it_should_behave_like "REST index action"
it_should_behave_like "REST show action"
end
gives the following output with 0.9.4:
% spec -fs a_spec.rb
FooController
- should return status code 200
- should return status code 200
It would be better, IMHO, if it looked like:
FooController
- should behave like REST index action and:
- should return status code 200
- should behave like REST show action and:
- should return status code 200
What do you guys think?
----------------------------------------------------------------------
>Comment By: Greg Spurrier (gregspurrier)
Date: 2007-05-11 11:38
Message:
I can certainly see your point for simple examples like the
one in the
docs:
Officer
- should be payable
- should be bonusable
- should be optionable
is indeed preferable to:
Officer
- should behave like All Managers, and:
- should behave like All Employees, and :
- be bonusable
- be payable
- be optionable
Let me describe the root issue that I'm grappling with and that
initially led me to request hierarchical output. Perhaps
there's a
beter way.
How do you deal with subclasses that should share multiple
behaviors
with their superclass. E.g., suppose you have:
class A
#...
end
class B < A
# ...
end
and behaviors like:
describe "A when it is sunny", :shared => true do
end
describe "A when it is cloudy", :shared => true do
end
For B, you can do:
describe "B when it is sunny" do
it_should_behave_like "A when it is sunny"
end
describe "B when it is cloudy" do
it_should_behave_like "A when it is cloudy"
end
and, maybe that's the right way to do it. But, it leads to
a lot of
repeated typing when A has a lot of shared behaviors or
there are a
lot of subclasses of A.
So, I was thinking about doing something like this for A:
describe "A", :shared => true do
it_should_behave_like "A when it is sunny"
it_should_behave_like "A when is is cloudy"
end
And for B:
describe "B inherited behavior" do
it_should_behave_like "A"
end
The advantage of this approach is that you can continue to
add shared
behaviors to the "A" description without having to go update
the specs
of all the subclasses.
But, with the current specdoc output, this aggregating of shared
behaviors into another shared behavior would be pretty
confusing in
the output.
Maybe there's another way to tackle this. Suggestions?
----------------------------------------------------------------------
Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-11 11:13
Message:
Personally I think that makes things more confusing.
----------------------------------------------------------------------
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=10781&group_id=797