Interesting shared behaviour side-effect

Testing RSpec
1

Given the following ApplicationController specs:

describe ApplicationController, “one facet”, :shared => true do
it ‘foo’ …
it ‘bar’ …
end

describe ApplicationController, “some other facet”, :shared =>
true do
it ‘abc’ …
it ‘xyz’ …
end

describe ApplicationController, :shared => true do
it_should_behave_like ‘ApplicationController one facet’
it_should_behave_like ‘ApplicationController some other facet’
end

And corresponding ApplicationController subclass specs:

describe OtherController do
it_should_behave_like ‘ApplicationController’
end

Both of the shared behaviour blocks get executed twice when running
the subclass specs; the specdoc output looks like:

OtherController

  • foo
  • bar
  • abc
  • xyz
  • abc
  • xyz
  • foo
  • bar

And note that it’s running the shared behaviours in this order:

  • ‘one facet’
  • ‘some other facet’
  • ‘some other facet’
  • ‘one facet’

Not actually a big deal; seeing as the specs don’t have any side-
effects and running them twice is harmless, and in any case getting
rid of the nesting (putting all the specs in a single shared
behaviour block) gets rid of the duplicate. But I’m wondering, is
this a bug? Feature? Am I abusing shared behaviours?

Cheers,
Wincent

2

On 21 Oct 2007, at 11:01, Wincent C. wrote:

Not actually a big deal; seeing as the specs don’t have any side-
effects and running them twice is harmless, and in any case getting
rid of the nesting (putting all the specs in a single shared
behaviour block) gets rid of the duplicate. But I’m wondering, is
this a bug? Feature? Am I abusing shared behaviours?

FWIW, this is something that also bites me frequently when wanting to
write multiple shared behaviours for mixins. I’ve resorted to
abandoning “higher-order” shared behaviours and using helper methods
instead (def it_should_behave_like_my_mixin; describe … :shared =>
true do … end; describe … :shared => true do … end;
describe … do it_should_behave_like … end; end) to bundle
together several related behaviours for injection into multiple specs.

(As an aside, these helpers often have to be parametric in the target
class so that their before(:each) blocks can create new instances –
this all feels pretty clumsy but I just couldn’t get it to work with
an instance created in before(:each) in the target spec because the
shared behaviours get run multiple times and it looks like external
state leaks between them.)

So yes, +1, someone please explain the right way to do these things! :wink:

Cheers,
-Tom

3

On 10/21/07, Wincent C. [email protected] wrote:

 it 'xyz' ...
 it_should_behave_like 'ApplicationController'
  • abc

Not actually a big deal; seeing as the specs don’t have any side-
effects and running them twice is harmless, and in any case getting
rid of the nesting (putting all the specs in a single shared
behaviour block) gets rid of the duplicate. But I’m wondering, is
this a bug? Feature? Am I abusing shared behaviours?

Yes. No. Yes (but you’re entitled to).

Please report this to the tracker!

Thanks,
David

4

On 10/21/07, Ashley M. [email protected] wrote:

   it "should do something else"

describe Cat do
end
@cat.prod
end

ie shift the method call into the “given”. Personally I prefer the
first way, as I like to formulate everything as a GWT unless I really
can’t. But every time I look at RSpec (example) code it seems like
the recommended way of structuring specs changes.

That’s how we do it because we don’t have the facet facility. For now,
however, there are too many other moving parts to consider the
additional layer. I would definitely consider it down the road.

Cheers,
David

5

On Oct 21, 2007, at 11:01 am, Wincent C. wrote:

And note that it’s running the shared behaviours in this order:

  • ‘one facet’
  • ‘some other facet’
  • ‘some other facet’
  • ‘one facet’

On a similar note, AGES ago, I promised to submit a patch for
something I ripped out of the rspec-ext gem, which lets you do this:

describe “something” do
facet “one facet” do
it “should do something”
it “and a bit more”
end
facet “another facet” do
it “should do something else”
end
end

to output something like:

something
- one facet: should do something
- one facet: and a bit more
- another facet: should do something else

I found it invaluable in long controller specs that have several
specs for loading, saving, validation etc. It also helps you
logically group related specs together in a spec. I started trying
to update the patch yesterday, but got stuck because the trunk has
moved on. Before I spend too long on it, I have questions:

  • is this still useful to anyone here?

  • is this good style? I am wondering if instead of

    describe Cat do
    before(:each) do
    @cat = Cat.new
    end
    facet “prod” do
    it “should miaow when sent :prod”
    it “should scratch when sent :prod”
    end
    facet “eat_food” do
    it “should eat food when sent :eat_food”
    it “should sleep after eating food when sent :eat_food”
    end
    end

you should write

describe Cat, “.prod” do
before(:each) do
@cat = Cat.new
end
it “should miaow when sent :prod” do
# …
@cat.prod
end
it “should scratch when sent :prod”
end

describe Cat, “.eat_food” do
before(:each) do
@cat = Cat.new
end
it “should eat food when sent :eat_food”
it “should sleep after eating food when sent :eat_food”
end

ie shift the method call into the “given”. Personally I prefer the
first way, as I like to formulate everything as a GWT unless I really
can’t. But every time I look at RSpec (example) code it seems like
the recommended way of structuring specs changes.

Ashley

–
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home

6

On 10/21/07, Ashley M. [email protected] wrote:

me a while to figure out where everything has to go (in the specs
that is, the code isn’t too hard).

Is it worth me working on this? It’s something I’d really like.

Please wait on this. As I said earlier this thread, there are too many
moving parts right now. Story Runner is still very new (not yet
released) and our plan is to use the Spec Runner formats for Story
Runner so the output looks uniform whether you’re running Stories or
Specs in any supported format (plain text/html/textmate, etc). Until
that (which is higher priority than adding facets) is resolved, I
don’t want to complicate what’s there now.

Once that is resolved, however, I’ll be happy to entertain this idea.

  • example one
  • example two
  • facet two
    • example three
    • facet three
      • example four

I think that in the end we’d want the latter. Don’t forget that this
will require changes to the html formatters as well as plain text.

Cheers,
David

7

On Oct 21, 2007, at 1:42 pm, David C. wrote:

That’s how we do it because we don’t have the facet facility. For now,
however, there are too many other moving parts to consider the
additional layer. I would definitely consider it down the road.

That’s ok, I was asking because I was happy to prepare a patch for
it. If I get a few hours I’ll have another go. The internals of
RSpec don’t look much like the external DSL, that’s why it was taking
me a while to figure out where everything has to go (in the specs
that is, the code isn’t too hard).

Is it worth me working on this? It’s something I’d really like.

While I’m thinking about it - in an ideal world, would better output be:

SomeClass

  • facet one: example one
  • facet one: example two
  • facet two: example three
  • facet two: facet three: example four

SomeClass

  • facet one
    • example one
    • example two
  • facet two
    • example three
    • facet three
      • example four

Ashley

–
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home

8

El 21/10/2007, a las 14:42, “David C.” [email protected]
escribió:

Please report this to the tracker!

Done:

<http://rubyforge.org/tracker/index.php?
func=detail&aid=14923&group_id=797&atid=3149>

Cheers,
Wincent

9

On Oct 21, 2007, at 2:34 pm, David C. wrote:

Please wait on this. As I said earlier this thread, there are too many
moving parts right now. Story Runner is still very new (not yet
released) and our plan is to use the Spec Runner formats for Story
Runner so the output looks uniform whether you’re running Stories or
Specs in any supported format (plain text/html/textmate, etc). Until
that (which is higher priority than adding facets) is resolved, I
don’t want to complicate what’s there now.

Once that is resolved, however, I’ll be happy to entertain this idea.

Ok I’ll hang fire.

I think that in the end we’d want the latter. Don’t forget that this
will require changes to the html formatters as well as plain text.

I thought about that. I actually rely on them more (via TextMate)
than the specdoc output.

Ashley

–
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home