Wincent Colaiuta
2007-Oct-21 10:01 UTC
[rspec-users] Interesting shared behaviour side-effect
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
On 21 Oct 2007, at 11:01, Wincent Colaiuta 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! ;-) Cheers, -Tom
David Chelimsky
2007-Oct-21 10:47 UTC
[rspec-users] Interesting shared behaviour side-effect
On 10/21/07, Wincent Colaiuta <win at wincent.com> wrote:> 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?Yes. No. Yes (but you''re entitled to). Please report this to the tracker! Thanks, David
On Oct 21, 2007, at 11:01 am, Wincent Colaiuta 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 @ aviewfromafar.net linked-in @ linkedin.com/in/ashleymoran currently @ home
David Chelimsky
2007-Oct-21 12:42 UTC
[rspec-users] Interesting shared behaviour side-effect
On 10/21/07, Ashley Moran <work at ashleymoran.me.uk> wrote:> > On Oct 21, 2007, at 11:01 am, Wincent Colaiuta 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.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
On Oct 21, 2007, at 1:42 pm, David Chelimsky 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 @ aviewfromafar.net linked-in @ linkedin.com/in/ashleymoran currently @ home
David Chelimsky
2007-Oct-21 13:34 UTC
[rspec-users] Interesting shared behaviour side-effect
On 10/21/07, Ashley Moran <work at ashleymoran.me.uk> wrote:> > On Oct 21, 2007, at 1:42 pm, David Chelimsky 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.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.> 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 fourI 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
On Oct 21, 2007, at 2:34 pm, David Chelimsky 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 @ aviewfromafar.net linked-in @ linkedin.com/in/ashleymoran currently @ home
Wincent Colaiuta
2007-Oct-21 17:42 UTC
[rspec-users] Interesting shared behaviour side-effect
El 21/10/2007, a las 14:42, "David Chelimsky" <dchelimsky at gmail.com> escribi?:> > On 10/21/07, Wincent Colaiuta <win at wincent.com> 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? > > Yes. No. Yes (but you''re entitled to). > > Please report this to the tracker!Done: <rubyforge.org/tracker/index.php? func=detail&aid=14923&group_id=797&atid=3149> Cheers, Wincent