I''m trying to use it_should_behave_like, and something seems to be wonky with the syntax. When I add :shared=>true, the DSL complains that the next line is the fixture declaration: /vendor/plugins/rspec/lib/spec/dsl/behaviour_eval.rb:137:in `method_missing'': undefined method `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> (NoMethodError) Here''s the spec http://pastie.caboo.se/72287 Am I using it_should_behave_like properly? Am I making a separate mistake? I have RSpec setup as a svn external (currently rev2101). Thanks, Jordan http://jordan.mckible.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070621/f5da66f8/attachment.html
I think a shared describe block can only take two arguments: 1. a string - the name of the shared behavior 2. the parameter saying that it is shared (:shared => true) Let me know if I''m wrong on this. Scott On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote:> I''m trying to use it_should_behave_like, and something seems to be > wonky with the syntax. When I add :shared=>true, the DSL complains > that the next line is the fixture declaration: > > /vendor/plugins/rspec/lib/spec > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> (NoMethodError) > > Here''s the spec http://pastie.caboo.se/72287 > > Am I using it_should_behave_like properly? Am I making a separate > mistake? I have RSpec setup as a svn external (currently rev2101). > > Thanks, > Jordan > http://jordan.mckible.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
What is the shared behavior between these two? Do you want a valid, saved, and accepted contract to act like an unaccepted contract? Abstract out what is common between them, and then use that as the shared description. See: http://pastie.caboo.se/72413 Best, Scott On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote:> I''m trying to use it_should_behave_like, and something seems to be > wonky with the syntax. When I add :shared=>true, the DSL complains > that the next line is the fixture declaration: > > /vendor/plugins/rspec/lib/spec > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> (NoMethodError) > > Here''s the spec http://pastie.caboo.se/72287 > > Am I using it_should_behave_like properly? Am I making a separate > mistake? I have RSpec setup as a svn external (currently rev2101). > > Thanks, > Jordan > http://jordan.mckible.com > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 6/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > What is the shared behavior between these two? Do you want a valid, > saved, and accepted contract to act like an unaccepted contract? > Abstract out what is common between them, and then use that as the > shared description. > > See: http://pastie.caboo.se/72413FYI - fixtures in shared behaviours don''t ever get called. Just declare them in the behaviours that use them.> > Best, > > Scott > > > On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote: > > > I''m trying to use it_should_behave_like, and something seems to be > > wonky with the syntax. When I add :shared=>true, the DSL complains > > that the next line is the fixture declaration: > > > > /vendor/plugins/rspec/lib/spec > > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method > > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> (NoMethodError) > > > > Here''s the spec http://pastie.caboo.se/72287 > > > > Am I using it_should_behave_like properly? Am I making a separate > > mistake? I have RSpec setup as a svn external (currently rev2101). > > > > Thanks, > > Jordan > > http://jordan.mckible.com > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Scott, putting aside semantics of the spec for a second, the code you posted generated the same error for me. According to David, it would seem this is because fixtures aren''t called in shared behaviors. So a shared context is really just an easy way of adding a bunch of specs to another context? Does it follow that shared contexts shouldn''t use before/after methods either? On 6/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:> > On 6/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > > > > What is the shared behavior between these two? Do you want a valid, > > saved, and accepted contract to act like an unaccepted contract? > > Abstract out what is common between them, and then use that as the > > shared description. > > > > See: http://pastie.caboo.se/72413 > > FYI - fixtures in shared behaviours don''t ever get called. Just > declare them in the behaviours that use them. > > > > > Best, > > > > Scott > > > > > > On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote: > > > > > I''m trying to use it_should_behave_like, and something seems to be > > > wonky with the syntax. When I add :shared=>true, the DSL complains > > > that the next line is the fixture declaration: > > > > > > /vendor/plugins/rspec/lib/spec > > > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method > > > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> (NoMethodError) > > > > > > Here''s the spec http://pastie.caboo.se/72287 > > > > > > Am I using it_should_behave_like properly? Am I making a separate > > > mistake? I have RSpec setup as a svn external (currently rev2101). > > > > > > Thanks, > > > Jordan > > > http://jordan.mckible.com > > > > > > _______________________________________________ > > > rspec-users mailing list > > > rspec-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070621/7a285d97/attachment.html
On Jun 21, 2007, at 12:55 PM, David Chelimsky wrote:> On 6/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >> >> What is the shared behavior between these two? Do you want a valid, >> saved, and accepted contract to act like an unaccepted contract? >> Abstract out what is common between them, and then use that as the >> shared description. >> >> See: http://pastie.caboo.se/72413 > > FYI - fixtures in shared behaviours don''t ever get called. Just > declare them in the behaviours that use them. >Ah. Good to know. Jordan: One option is to add specification blocks in the shared behavior, and then define the instance variables per description, i.e.: http://pastie.caboo.se/72418 Scott
On Jun 21, 2007, at 1:01 PM, Jordan McKible wrote:> Scott, putting aside semantics of the spec for a second, the code > you posted generated the same error for me. According to David, it > would seem this is because fixtures aren''t called in shared behaviors. > > Does it follow that shared contexts shouldn''t use before/after > methods either?I would imagine that it could be done, although I don''t know about the implementation of rspec with this detail (so it may be the case that the before and after methods override those defined in the shared behavior...). Even if the before and after methods don''t override those in the shared behavior, I would image that you should only define instance variables which would be shared among all the specs. Scott
On 6/21/07, Jordan McKible <jmckible at gmail.com> wrote:> Scott, putting aside semantics of the spec for a second, the code you posted > generated the same error for me. According to David, it would seem this is > because fixtures aren''t called in shared behaviors. > > So a shared context is really just an easy way of adding a bunch of specs to > another context? Does it follow that shared contexts shouldn''t use > before/after methods either?before and after both work, and don''t override the ones in the specs. The before''s in the shared behaviour happen before the before''s in the including behaviour, and vice versa for the afters.> > > On 6/21/07, David Chelimsky <dchelimsky at gmail.com> wrote: > > On 6/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > > > > > > What is the shared behavior between these two? Do you want a valid, > > > saved, and accepted contract to act like an unaccepted contract? > > > Abstract out what is common between them, and then use that as the > > > shared description. > > > > > > See: http://pastie.caboo.se/72413 > > > > FYI - fixtures in shared behaviours don''t ever get called. Just > > declare them in the behaviours that use them. > > > > > > > > Best, > > > > > > Scott > > > > > > > > > On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote: > > > > > > > I''m trying to use it_should_behave_like, and something seems to be > > > > wonky with the syntax. When I add :shared=>true, the DSL complains > > > > that the next line is the fixture declaration: > > > > > > > > /vendor/plugins/rspec/lib/spec > > > > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method > > > > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> > (NoMethodError) > > > > > > > > Here''s the spec http://pastie.caboo.se/72287 > > > > > > > > Am I using it_should_behave_like properly? Am I making a separate > > > > mistake? I have RSpec setup as a svn external (currently rev2101). > > > > > > > > Thanks, > > > > Jordan > > > > http://jordan.mckible.com > > > > > > > > _______________________________________________ > > > > rspec-users mailing list > > > > rspec-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > _______________________________________________ > > > rspec-users mailing list > > > rspec-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
"David Chelimsky" <dchelimsky at gmail.com> writes:> On 6/21/07, Jordan McKible <jmckible at gmail.com> wrote: >> Scott, putting aside semantics of the spec for a second, the code you posted >> generated the same error for me. According to David, it would seem this is >> because fixtures aren''t called in shared behaviors. >> >> So a shared context is really just an easy way of adding a bunch of specs to >> another context? Does it follow that shared contexts shouldn''t use >> before/after methods either? > > before and after both work, and don''t override the ones in the specs. > The before''s in the shared behaviour happen before the before''s in the > including behaviour, and vice versa for the afters.Actually the before''s happen in the order they are encountered in the non-shared behavior. i.e. The order of before and is_should_behave_like are kept: describe "First", :shared => true do before(:all) do puts "First shared all" end it "should say ''What!?''" do puts "What!?" end end describe "Second", :shared => true do before(:all) do puts "Second shared all" end it "should say ''What!?'' again" do puts "What again" end end describe "Non shared" do it_should_behave_like "First" before(:all) do puts "first NON-shared all" end it_should_behave_like "Second" before(:all) do puts "second NON-shared all" end it "should print the them in order" do puts "non-shared example" end end> spec shared_behavior_example.rbFirst shared all first NON-shared all Second shared all second NON-shared all What!? .What again .non-shared example . - Bob> >> >> >> On 6/21/07, David Chelimsky <dchelimsky at gmail.com> wrote: >> > On 6/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >> > > >> > > What is the shared behavior between these two? Do you want a valid, >> > > saved, and accepted contract to act like an unaccepted contract? >> > > Abstract out what is common between them, and then use that as the >> > > shared description. >> > > >> > > See: http://pastie.caboo.se/72413 >> > >> > FYI - fixtures in shared behaviours don''t ever get called. Just >> > declare them in the behaviours that use them. >> > >> > > >> > > Best, >> > > >> > > Scott >> > > >> > > >> > > On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote: >> > > >> > > > I''m trying to use it_should_behave_like, and something seems to be >> > > > wonky with the syntax. When I add :shared=>true, the DSL complains >> > > > that the next line is the fixture declaration: >> > > > >> > > > /vendor/plugins/rspec/lib/spec >> > > > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method >> > > > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> >> (NoMethodError) >> > > > >> > > > Here''s the spec http://pastie.caboo.se/72287 >> > > > >> > > > Am I using it_should_behave_like properly? Am I making a separate >> > > > mistake? I have RSpec setup as a svn external (currently rev2101). >> > > > >> > > > Thanks, >> > > > Jordan >> > > > http://jordan.mckible.com >> > > > >> > > > _______________________________________________ >> > > > rspec-users mailing list >> > > > rspec-users at rubyforge.org >> > > > http://rubyforge.org/mailman/listinfo/rspec-users >> > > >> > > _______________________________________________ >> > > rspec-users mailing list >> > > rspec-users at rubyforge.org >> > > http://rubyforge.org/mailman/listinfo/rspec-users >> > > >> > _______________________________________________ >> > rspec-users mailing list >> > rspec-users at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/rspec-users >> > >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 6/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:> "David Chelimsky" <dchelimsky at gmail.com> writes: > > > On 6/21/07, Jordan McKible <jmckible at gmail.com> wrote: > >> Scott, putting aside semantics of the spec for a second, the code you posted > >> generated the same error for me. According to David, it would seem this is > >> because fixtures aren''t called in shared behaviors. > >> > >> So a shared context is really just an easy way of adding a bunch of specs to > >> another context? Does it follow that shared contexts shouldn''t use > >> before/after methods either? > > > > before and after both work, and don''t override the ones in the specs. > > The before''s in the shared behaviour happen before the before''s in the > > including behaviour, and vice versa for the afters. > > Actually the before''s happen in the order they are encountered in the > non-shared behavior. i.e. The order of before and > is_should_behave_like are kept: > > > > > describe "First", :shared => true do > before(:all) do > puts "First shared all" > end > > it "should say ''What!?''" do > puts "What!?" > end > end > > describe "Second", :shared => true do > before(:all) do > puts "Second shared all" > end > > it "should say ''What!?'' again" do > puts "What again" > end > end > > describe "Non shared" do > > it_should_behave_like "First" > > before(:all) do > puts "first NON-shared all" > end > > it_should_behave_like "Second" > > before(:all) do > puts "second NON-shared all" > end > > it "should print the them in order" do > puts "non-shared example" > end > end > > > spec shared_behavior_example.rb > > First shared all > first NON-shared all > Second shared all > second NON-shared all > What!? > .What again > .non-shared exampleThat makes sense. Thanks for the clarification. FYI - when this email came in my growl notifier read "it_should_behave_like Bob Cotton." Hope you find that as amusing as I did. Cheers, David> . > > > - Bob > > > > >> > >> > >> On 6/21/07, David Chelimsky <dchelimsky at gmail.com> wrote: > >> > On 6/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >> > > > >> > > What is the shared behavior between these two? Do you want a valid, > >> > > saved, and accepted contract to act like an unaccepted contract? > >> > > Abstract out what is common between them, and then use that as the > >> > > shared description. > >> > > > >> > > See: http://pastie.caboo.se/72413 > >> > > >> > FYI - fixtures in shared behaviours don''t ever get called. Just > >> > declare them in the behaviours that use them. > >> > > >> > > > >> > > Best, > >> > > > >> > > Scott > >> > > > >> > > > >> > > On Jun 21, 2007, at 10:24 AM, Jordan McKible wrote: > >> > > > >> > > > I''m trying to use it_should_behave_like, and something seems to be > >> > > > wonky with the syntax. When I add :shared=>true, the DSL complains > >> > > > that the next line is the fixture declaration: > >> > > > > >> > > > /vendor/plugins/rspec/lib/spec > >> > > > /dsl/behaviour_eval.rb:137:in `method_missing'': undefined method > >> > > > `fixtures'' for #<Spec::DSL::EvalModule:0x324a2cc> > >> (NoMethodError) > >> > > > > >> > > > Here''s the spec http://pastie.caboo.se/72287 > >> > > > > >> > > > Am I using it_should_behave_like properly? Am I making a separate > >> > > > mistake? I have RSpec setup as a svn external (currently rev2101). > >> > > > > >> > > > Thanks, > >> > > > Jordan > >> > > > http://jordan.mckible.com > >> > > > > >> > > > _______________________________________________ > >> > > > rspec-users mailing list > >> > > > rspec-users at rubyforge.org > >> > > > http://rubyforge.org/mailman/listinfo/rspec-users > >> > > > >> > > _______________________________________________ > >> > > rspec-users mailing list > >> > > rspec-users at rubyforge.org > >> > > http://rubyforge.org/mailman/listinfo/rspec-users > >> > > > >> > _______________________________________________ > >> > rspec-users mailing list > >> > rspec-users at rubyforge.org > >> > http://rubyforge.org/mailman/listinfo/rspec-users > >> > > >> > >> > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > >> > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Maybe Matching Threads
- Running specs for a plugin - undefined method ''define'' for object
- used the described Class in a shared behavior
- Specs for ApplicationController, where to put them?
- Controller specs not shareable?
- authentication, controller specs. I think I''m missing something simple ....