On Nov 6, 2007 8:11 AM, Tom Stuart <[EMAIL PROTECTED]> wrote: > On 6 Nov 2007, at 02:00, Jim Lindley wrote: > > Add an additional describe block for the class that you're including > > the module into, and then setup a genericly named object in the before > > block > [...] > > > > # page_spec.rb > > describe Page, "should include publishing features" do > > include PublishableSpec > > > > before(:each) do > > @model = Page.new(:title => "title", :content => "content", > > :published => false) > > end > > Yeah, this is fine for a simple mixin with only one shared behaviour, > but the problem is that a real chunk of mixed-in functionality will > probably need many behaviours that correspond to different initial > states (provided you're behaving yourself and not doing too much state > setup within the individual examples). > > So, firstly, perhaps I'll have ten shared behaviours to specify my > mixin -- do I have ten calls to it_should_behave_like in the spec for > each target class? > > And secondly, perhaps each of those shared behaviours is talking about > an object with different initial state, e.g. constructed with > different arguments (a published thing, an unpublished thing, a > published but deleted thing) -- how do I arrange for that to happen? > Ten corresponding behaviours each containing the appropriate > before(:each) and a call to it_should_behave_like? Or arrange for the > shared behaviours to somehow do the initialisation themselves, e.g. by > doing some kind of parameterized helper gymnastics where you pass in > the child class object and the shared behaviour calls #new on it? > > None of this is impossible to do, it's just that it all feels very > repetitious and difficult in contrast to the elegant solutions that > people often post here.
There really isn't a great solution for this problem right now, but there are a few initiatives that will be helpful in getting us there. Nested specs, classes/methods (as an alternative to describe/it), turning examples into methods (so they can get overridden), etc, etc. > I'm hoping that this sort of "okay, you > understand the basics, but NOW what?" issue is the kind of thing that > the hotly-anticipated RSpec book will address, because any information > about best practice in this area is really lacking, but I fear it > might not be that kind of book! Well - there will be some of that, and we'll certainly consider including something about this issue. It's fairly common. Cheers, David > > Cheers, > -Tom > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
