I just stumbled upon this link this morning where Shoulda makes it easy to automatically load custom macros. Is there a similar feature in RSpec? http://technicalpickles.com/posts/shoulda-can-automatically-load-custom-macros Andy -- Posted via http://www.ruby-forum.com/.
We do something similar to this, though we use a convention to set @klass to the class being spec''d in the top-level example group, rather than deriving it as they do in that sample. In view specs we also use a convention to always have a do_render method available, so that we can bring in similarly shared / generated examples. It''s great for speccing two sublcasses which have some common behaviour, where it feels wrong to spec the (abstract) base class. On 30 Sep 2008, at 12:09, Andy Freeman wrote:> I just stumbled upon this link this morning where Shoulda makes it > easy > to automatically load custom macros. Is there a similar feature in > RSpec? > > http://technicalpickles.com/posts/shoulda-can-automatically-load-custom-macros > > Andy > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Are you willing to provide a simple example? Andy Matt Wynne wrote:> We do something similar to this, though we use a convention to set > @klass to the class being spec''d in the top-level example group, > rather than deriving it as they do in that sample. > > In view specs we also use a convention to always have a do_render > method available, so that we can bring in similarly shared / generated > examples. > > It''s great for speccing two sublcasses which have some common > behaviour, where it feels wrong to spec the (abstract) base class.-- Posted via http://www.ruby-forum.com/.
On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> wrote:> Are you willing to provide a simple example?I''m using the same example as the articled you linked to originally as the base. This way you should be able to clearly see the differences. http://gist.github.com/13804 Zach> > Andy > > Matt Wynne wrote: >> We do something similar to this, though we use a convention to set >> @klass to the class being spec''d in the top-level example group, >> rather than deriving it as they do in that sample. >> >> In view specs we also use a convention to always have a do_render >> method available, so that we can bring in similarly shared / generated >> examples. >> >> It''s great for speccing two sublcasses which have some common >> behaviour, where it feels wrong to spec the (abstract) base class. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com
Also, a nice thing about RSpec is that when you do describe an actual object, ie: "describe Foo", you can determine this by asking the example group what it''s described type is. This makes things a lot simpler and cleaner than having to hack away strings, or guess based on the name of your test. Zach On Tue, Sep 30, 2008 at 8:57 AM, Zach Dennis <zach.dennis at gmail.com> wrote:> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> wrote: >> Are you willing to provide a simple example? > > I''m using the same example as the articled you linked to originally as > the base. This way you should be able to clearly see the differences. > > http://gist.github.com/13804 > > Zach > >> >> Andy >> >> Matt Wynne wrote: >>> We do something similar to this, though we use a convention to set >>> @klass to the class being spec''d in the top-level example group, >>> rather than deriving it as they do in that sample. >>> >>> In view specs we also use a convention to always have a do_render >>> method available, so that we can bring in similarly shared / generated >>> examples. >>> >>> It''s great for speccing two sublcasses which have some common >>> behaviour, where it feels wrong to spec the (abstract) base class. >> >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com >-- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com
On Tue, Sep 30, 2008 at 7:59 AM, Zach Dennis <zach.dennis at gmail.com> wrote:> Also, a nice thing about RSpec is that when you do describe an actual > object, ie: "describe Foo", you can determine this by asking the > example group what it''s described type is. > > This makes things a lot simpler and cleaner than having to hack away > strings, or guess based on the name of your test. > > Zach > > On Tue, Sep 30, 2008 at 8:57 AM, Zach Dennis <zach.dennis at gmail.com> wrote: >> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> wrote: >>> Are you willing to provide a simple example? >> >> I''m using the same example as the articled you linked to originally as >> the base. This way you should be able to clearly see the differences. >> >> http://gist.github.com/13804Here''s a variation on that with a helper for defining macros that I''m thinking of adding to rspec. Lemme know what you think: http://gist.github.com/13821 Cheers, David>> >> Zach >> >>> >>> Andy >>> >>> Matt Wynne wrote: >>>> We do something similar to this, though we use a convention to set >>>> @klass to the class being spec''d in the top-level example group, >>>> rather than deriving it as they do in that sample. >>>> >>>> In view specs we also use a convention to always have a do_render >>>> method available, so that we can bring in similarly shared / generated >>>> examples. >>>> >>>> It''s great for speccing two sublcasses which have some common >>>> behaviour, where it feels wrong to spec the (abstract) base class. >>> >>> -- >>> Posted via http://www.ruby-forum.com/. >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> >> >> -- >> Zach Dennis >> http://www.continuousthinking.com >> http://www.mutuallyhuman.com >> > > > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
David Chelimsky wrote:> On Tue, Sep 30, 2008 at 7:59 AM, Zach Dennis <zach.dennis at gmail.com> wrote: > >> Also, a nice thing about RSpec is that when you do describe an actual >> object, ie: "describe Foo", you can determine this by asking the >> example group what it''s described type is. >> >> This makes things a lot simpler and cleaner than having to hack away >> strings, or guess based on the name of your test. >> >> Zach >> >> On Tue, Sep 30, 2008 at 8:57 AM, Zach Dennis <zach.dennis at gmail.com> wrote: >> >>> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> wrote: >>> >>>> Are you willing to provide a simple example? >>>> >>> I''m using the same example as the articled you linked to originally as >>> the base. This way you should be able to clearly see the differences. >>> >>> http://gist.github.com/13804 >>> > > Here''s a variation on that with a helper for defining macros that I''m > thinking of adding to rspec. Lemme know what you think: > > http://gist.github.com/13821 > > Cheers, > David > >+1 I like it. For rspec-rails it would also be nice to be able to say: define_macros(:for => :controller) do ... end define_macros(:for => :models) do ... end etc... Also, instead of yielding within another block you can simply pass in the given block as an arg: def define_macros(¯o_block) Spec::Example::ExampleGroupMethods.extend Module.new(¯o_block) end You probably knew this but I thought I would point it out because it seems that it would give you better performance. (I have not tested that assumption at all.) -Ben
On Tue, Sep 30, 2008 at 10:38 AM, Ben Mabey <ben at benmabey.com> wrote:> David Chelimsky wrote: >> >> On Tue, Sep 30, 2008 at 7:59 AM, Zach Dennis <zach.dennis at gmail.com> >> wrote: >> >>> >>> Also, a nice thing about RSpec is that when you do describe an actual >>> object, ie: "describe Foo", you can determine this by asking the >>> example group what it''s described type is. >>> >>> This makes things a lot simpler and cleaner than having to hack away >>> strings, or guess based on the name of your test. >>> >>> Zach >>> >>> On Tue, Sep 30, 2008 at 8:57 AM, Zach Dennis <zach.dennis at gmail.com> >>> wrote: >>> >>>> >>>> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> >>>> wrote: >>>> >>>>> >>>>> Are you willing to provide a simple example? >>>>> >>>> >>>> I''m using the same example as the articled you linked to originally as >>>> the base. This way you should be able to clearly see the differences. >>>> >>>> http://gist.github.com/13804 >>>> >> >> Here''s a variation on that with a helper for defining macros that I''m >> thinking of adding to rspec. Lemme know what you think: >> >> http://gist.github.com/13821 >> >> Cheers, >> David >> >> > > +1 > I like it. For rspec-rails it would also be nice to be able to say: > > define_macros(:for => :controller) do > ... > end > > define_macros(:for => :models) do > ... > end > etc... > > Also, instead of yielding within another block you can simply pass in the > given block as an arg: > > def define_macros(¯o_block) > Spec::Example::ExampleGroupMethods.extend Module.new(¯o_block) > end > > You probably knew this but I thought I would point it out because it seems > that it would give you better performance. (I have not tested that > assumption at all.) >I like David''s suggestion and I also like Ben''s suggestion on top of it. +1 to both. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com
What''s not to like?! Despite the fact that a new RSpec version was just released, it would be nice to see a new version released right away with this concept built in so that a RSpec version of Shoulda could start rolling. :) David Chelimsky wrote:> On Tue, Sep 30, 2008 at 7:59 AM, Zach Dennis <zach.dennis at gmail.com> > wrote: >>> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> wrote: >>>> Are you willing to provide a simple example? >>> >>> I''m using the same example as the articled you linked to originally as >>> the base. This way you should be able to clearly see the differences. >>> >>> http://gist.github.com/13804 > > Here''s a variation on that with a helper for defining macros that I''m > thinking of adding to rspec. Lemme know what you think: > > http://gist.github.com/13821 > > Cheers, > David-- Posted via http://www.ruby-forum.com/.
On Tue, Sep 30, 2008 at 9:38 AM, Ben Mabey <ben at benmabey.com> wrote:> David Chelimsky wrote: >> >> On Tue, Sep 30, 2008 at 7:59 AM, Zach Dennis <zach.dennis at gmail.com> >> wrote: >> >>> >>> Also, a nice thing about RSpec is that when you do describe an actual >>> object, ie: "describe Foo", you can determine this by asking the >>> example group what it''s described type is. >>> >>> This makes things a lot simpler and cleaner than having to hack away >>> strings, or guess based on the name of your test. >>> >>> Zach >>> >>> On Tue, Sep 30, 2008 at 8:57 AM, Zach Dennis <zach.dennis at gmail.com> >>> wrote: >>> >>>> >>>> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> >>>> wrote: >>>> >>>>> >>>>> Are you willing to provide a simple example? >>>>> >>>> >>>> I''m using the same example as the articled you linked to originally as >>>> the base. This way you should be able to clearly see the differences. >>>> >>>> http://gist.github.com/13804 >>>> >> >> Here''s a variation on that with a helper for defining macros that I''m >> thinking of adding to rspec. Lemme know what you think: >> >> http://gist.github.com/13821 >> >> Cheers, >> David >> >> > > +1 > I like it. For rspec-rails it would also be nice to be able to say: > > define_macros(:for => :controller) do > ... > end > > define_macros(:for => :models) do > ... > end > etc... > > Also, instead of yielding within another block you can simply pass in the > given block as an arg: > > def define_macros(¯o_block) > Spec::Example::ExampleGroupMethods.extend Module.new(¯o_block) > endClose but not quite. Here are two similar examples that work: def define_macros(&block) Spec::Example::ExampleGroupMethods.module_eval(&block) end def define_macros(&block) Spec::Example::ExampleGroupMethods.extend Module.new(&block.call) end I think the first is nicer if we''re not too concerned with control or traceability, but the second, w/ the Module.new on a separate line, would support maintaining references to the module (if that would be useful). Cheers, David> You probably knew this but I thought I would point it out because it seems > that it would give you better performance. (I have not tested that > assumption at all.) > > -Ben
On Tue, Sep 30, 2008 at 10:18 PM, Andy Freeman <lists at ruby-forum.com> wrote:> David Chelimsky wrote: >> On Tue, Sep 30, 2008 at 7:59 AM, Zach Dennis <zach.dennis at gmail.com> >> wrote: >>>> On Tue, Sep 30, 2008 at 8:41 AM, Andy Freeman <lists at ruby-forum.com> wrote: >>>>> Are you willing to provide a simple example? >>>> >>>> I''m using the same example as the articled you linked to originally as >>>> the base. This way you should be able to clearly see the differences. >>>> >>>> http://gist.github.com/13804 >> >> Here''s a variation on that with a helper for defining macros that I''m >> thinking of adding to rspec. Lemme know what you think: >> >> http://gist.github.com/13821> What''s not to like?! Despite the fact that a new RSpec version was just > released, it would be nice to see a new version released right away with > this concept built in so that a RSpec version of Shoulda could start > rolling. :)Not quite sure how we got from discussing an idea to release planning, but the idea of a shoulda-like library built on this is a good one. If you''re planning on writing one, no need to wait for this to appear in rspec. It''s 3 lines of code that you could include in such a library until such time as it is released w/ RSpec. Cheers, David>> >> Cheers, >> David
I was actually teasing... :) As far as writing one... already on it! David Chelimsky wrote:> On Tue, Sep 30, 2008 at 10:18 PM, Andy Freeman <lists at ruby-forum.com> > wrote: >>> >>> Here''s a variation on that with a helper for defining macros that I''m >>> thinking of adding to rspec. Lemme know what you think: >>> >>> http://gist.github.com/13821 > >> What''s not to like?! Despite the fact that a new RSpec version was just >> released, it would be nice to see a new version released right away with >> this concept built in so that a RSpec version of Shoulda could start >> rolling. :) > > Not quite sure how we got from discussing an idea to release planning, > but the idea of a shoulda-like library built on this is a good one. If > you''re planning on writing one, no need to wait for this to appear in > rspec. It''s 3 lines of code that you could include in such a library > until such time as it is released w/ RSpec. > > Cheers, > David-- Posted via http://www.ruby-forum.com/.
It is a bit ugly but here is an initial port of the Shoulda ActiveRecord macros: http://gist.github.com/14050 I did not try running ALL of the macros, but most of them. Before going too far with it, I would appreciate some recommendations as to how to improve the flow. The Shoulda version has a different feel to it since the assertions cause the code to die early. Whereas the RSpec conversion I did mostly wrap each should call in its own it block. Thanks for the help! I learned a lot from this exercise! Andy David Chelimsky wrote:> On Tue, Sep 30, 2008 at 9:38 AM, Ben Mabey <ben at benmabey.com> wrote: >>>> This makes things a lot simpler and cleaner than having to hack away >>>>> >>> Here''s a variation on that with a helper for defining macros that I''m >> I like it. For rspec-rails it would also be nice to be able to say: >> Also, instead of yielding within another block you can simply pass in the >> given block as an arg: >> >> def define_macros(¯o_block) >> Spec::Example::ExampleGroupMethods.extend Module.new(¯o_block) >> end > > Close but not quite. Here are two similar examples that work: > > def define_macros(&block) > Spec::Example::ExampleGroupMethods.module_eval(&block) > end > > def define_macros(&block) > Spec::Example::ExampleGroupMethods.extend Module.new(&block.call) > end > > I think the first is nicer if we''re not too concerned with control or > traceability, but the second, w/ the Module.new on a separate line, > would support maintaining references to the module (if that would be > useful). > > Cheers, > David-- Posted via http://www.ruby-forum.com/.
I updated the gist posting. All of the macros should be functional now and have cleaned up describe blocks. http://gist.github.com/14050 Andy Freeman wrote:> It is a bit ugly but here is an initial port of the Shoulda ActiveRecord > macros: > > http://gist.github.com/14050 > > I did not try running ALL of the macros, but most of them. Before going > too far with it, I would appreciate some recommendations as to how to > improve the flow. The Shoulda version has a different feel to it since > the assertions cause the code to die early. Whereas the RSpec > conversion I did mostly wrap each should call in its own it block. > > Thanks for the help! I learned a lot from this exercise! > > Andy-- Posted via http://www.ruby-forum.com/.