[rspec-devel] [ rspec-Feature Requests-10781 ] Hierarchical specdoc output for shared behaviors

noreply at rubyforge.org noreply at rubyforge.org
Fri May 11 19:11:59 EDT 2007


Feature Requests item #10781, was opened at 2007-05-11 17: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: David Chelimsky (dchelimsky)
Date: 2007-05-11 23:11

Message:
I hadn't really thought of shared behaviours as being about context. I think that the "concrete" behaviours that use them are where context should be expressed.

I see the problem, but I feel like this is a misuse of shared behaviors and that there is some other construct that is trying to be emerge here.

One thought is an RFE from a while back about "aspects" (or "facets"): http://rubyforge.org/tracker/?group_id=797&atid=3152&func=detail&aid=8654

Take a look at that and let me know what you think about it vis a vis this particular problem.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-11 23:06

Message:
OK, now I understand the problem better. Let me think on it for a bit.

----------------------------------------------------------------------

Comment By: Greg Spurrier (gregspurrier)
Date: 2007-05-11 22:18

Message:
The output you describe is great, but it requires you to put
"if it's raining" in the description of each example that is
part of the "when it's raining" behavior, which seems redundant.

Writing the spec the natural way in which the descriptions
of the examples are taken to be within the context of the
description:

describe "A when it's sunny", :shared => true do
  it "should be open for business" do
  end

  it "should be use natural lighting" do
  end
end

describe "A when it's cloudy", :shared =>true do
  it "should be open for business" do
  end

  it "should be use electric lighting" do
  end
end                       

describe "A", :shared => true do
  it_should_behave_like "A when it's sunny"  
  it_should_behave_like "A when it's cloudy"  
end

describe "B's inherited behavior" do
  it_should_behave_like "A"
end 

gives:

B's inherited behavior
- should be open for business
- should be use natural lighting
- should be open for business
- should be use electric lighting

which is what I was referring to as being confusing.

It'd be nice if there was a way for the context of the
behavior to carry through to the specdoc output so that the
output can be unambiguous, but the specs can still read
naturally without having to explicitly include the context
in each example.



----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-11 19:10

Message:
Why would the output be confusing? Everything just gets flattened, so for an A that does 2 things when it rains and 2 other things when it's cloudy, with subclasses B and C, the output would say:

B
- should do thing 1 if it's raining
- should do thing 2 if it's raining
- should do thing 3 if it's cloudy
- should do thing 4 if it's cloudy

C
- should do thing 1 if it's raining
- should do thing 2 if it's raining
- should do thing 3 if it's cloudy
- should do thing 4 if it's cloudy

Looking at either listing, everything seems clear. What am I missing?

----------------------------------------------------------------------

Comment By: Greg Spurrier (gregspurrier)
Date: 2007-05-11 18: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 18: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


More information about the rspec-devel mailing list