I am completely baffled by this one - My guess is that there is no pure ruby way to do this - but how could I set up a spec to test that one method is an alias of another? Thanks for any help, Scott
On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > I am completely baffled by this one - My guess is that there is no > pure ruby way to do this - but how could I set up a spec to test that > one method is an alias of another?class Foo def bar end alias :baz :bar end context "Foo class" do specify "should use the same method for #baz as #bar" do Foo.instance_method(:baz).should == Foo.instance_method(:bar) end end context "Foo instance" do specify "should use the same method for #baz as #bar" do foo = Foo.new foo.method(:baz).should == foo.method(:bar) end end equal? won''t work because the resulting method isn''t the same object, but you''ll see that == fails when the implementations they point to are different. Hope that works for you. David> > Thanks for any help, > > Scott > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
But that doesn''t check that the methods are the same, does it? Doesn''t it only check if the values returned by the methods are equal (in this case, nil)? Scott On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote:> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >> >> I am completely baffled by this one - My guess is that there is no >> pure ruby way to do this - but how could I set up a spec to test that >> one method is an alias of another? > > class Foo > def bar > end > alias :baz :bar > end > > context "Foo class" do > specify "should use the same method for #baz as #bar" do > Foo.instance_method(:baz).should == Foo.instance_method(:bar) > end > end > > context "Foo instance" do > specify "should use the same method for #baz as #bar" do > foo = Foo.new > foo.method(:baz).should == foo.method(:bar) > end > end > > equal? won''t work because the resulting method isn''t the same object, > but you''ll see that == fails when the implementations they point to > are different. > > Hope that works for you. > > David > >> >> Thanks for any help, >> >> Scott >> >> _______________________________________________ >> 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 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > > But that doesn''t check that the methods are the same, does it? > Doesn''t it only check if the values returned by the methods are equal > (in this case, nil)?That''s not what I get from the docs: http://www.ruby-doc.org/core/classes/Module.html#M001682 Seems to me it''s an UnboundMethod object (or Method in the second example I gave). WDYT?> > Scott > > > On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote: > > > On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >> > >> I am completely baffled by this one - My guess is that there is no > >> pure ruby way to do this - but how could I set up a spec to test that > >> one method is an alias of another? > > > > class Foo > > def bar > > end > > alias :baz :bar > > end > > > > context "Foo class" do > > specify "should use the same method for #baz as #bar" do > > Foo.instance_method(:baz).should == Foo.instance_method(:bar) > > end > > end > > > > context "Foo instance" do > > specify "should use the same method for #baz as #bar" do > > foo = Foo.new > > foo.method(:baz).should == foo.method(:bar) > > end > > end > > > > equal? won''t work because the resulting method isn''t the same object, > > but you''ll see that == fails when the implementations they point to > > are different. > > > > Hope that works for you. > > > > David > > > >> > >> Thanks for any help, > >> > >> Scott > >> > >> _______________________________________________ > >> 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 >
Wow. Thanks. You''ve opened up a whole new world of ruby for me. I had never heard of an UnboundMethod object before. I should have RTFM''ed before I was so quick on my reply. Thanks a bunch, Scott On Mar 19, 2007, at 6:59 PM, David Chelimsky wrote:> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >> >> >> But that doesn''t check that the methods are the same, does it? >> Doesn''t it only check if the values returned by the methods are equal >> (in this case, nil)? > > That''s not what I get from the docs: > > http://www.ruby-doc.org/core/classes/Module.html#M001682 > > Seems to me it''s an UnboundMethod object (or Method in the second > example I gave). > > WDYT? > > >> >> Scott >> >> >> On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote: >> >>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>>> >>>> I am completely baffled by this one - My guess is that there is no >>>> pure ruby way to do this - but how could I set up a spec to test >>>> that >>>> one method is an alias of another? >>> >>> class Foo >>> def bar >>> end >>> alias :baz :bar >>> end >>> >>> context "Foo class" do >>> specify "should use the same method for #baz as #bar" do >>> Foo.instance_method(:baz).should == Foo.instance_method(:bar) >>> end >>> end >>> >>> context "Foo instance" do >>> specify "should use the same method for #baz as #bar" do >>> foo = Foo.new >>> foo.method(:baz).should == foo.method(:bar) >>> end >>> end >>> >>> equal? won''t work because the resulting method isn''t the same >>> object, >>> but you''ll see that == fails when the implementations they point to >>> are different. >>> >>> Hope that works for you. >>> >>> David >>> >>>> >>>> Thanks for any help, >>>> >>>> Scott >>>> >>>> _______________________________________________ >>>> 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 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > Wow. Thanks. You''ve opened up a whole new world of ruby for me. I > had never heard of an UnboundMethod object before.Now the fun begins!!!!! Cheers, David> > I should have RTFM''ed before I was so quick on my reply. > > Thanks a bunch, > > Scott > > > On Mar 19, 2007, at 6:59 PM, David Chelimsky wrote: > > > On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >> > >> > >> But that doesn''t check that the methods are the same, does it? > >> Doesn''t it only check if the values returned by the methods are equal > >> (in this case, nil)? > > > > That''s not what I get from the docs: > > > > http://www.ruby-doc.org/core/classes/Module.html#M001682 > > > > Seems to me it''s an UnboundMethod object (or Method in the second > > example I gave). > > > > WDYT? > > > > > >> > >> Scott > >> > >> > >> On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote: > >> > >>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >>>> > >>>> I am completely baffled by this one - My guess is that there is no > >>>> pure ruby way to do this - but how could I set up a spec to test > >>>> that > >>>> one method is an alias of another? > >>> > >>> class Foo > >>> def bar > >>> end > >>> alias :baz :bar > >>> end > >>> > >>> context "Foo class" do > >>> specify "should use the same method for #baz as #bar" do > >>> Foo.instance_method(:baz).should == Foo.instance_method(:bar) > >>> end > >>> end > >>> > >>> context "Foo instance" do > >>> specify "should use the same method for #baz as #bar" do > >>> foo = Foo.new > >>> foo.method(:baz).should == foo.method(:bar) > >>> end > >>> end > >>> > >>> equal? won''t work because the resulting method isn''t the same > >>> object, > >>> but you''ll see that == fails when the implementations they point to > >>> are different. > >>> > >>> Hope that works for you. > >>> > >>> David > >>> > >>>> > >>>> Thanks for any help, > >>>> > >>>> Scott > >>>> > >>>> _______________________________________________ > >>>> 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 >
This is cool, but I just gotta ask: Is this kind of a spec about behavior or low-level testing? I thought the whole zen of the spec thing was to describe desired behaviors programmatically. The notion being that these behaviors would be relatively coarse grained and the finer-grained (i.e., implementation details) would sort themselves out as you fix failures. The whole appeal to me is that you write the specs without suggesting too much about the implementation of the solution. What you''re describing here appears to be tied intimately with the implementation, so if you change that you break the spec, right? Just a thought :) On Mar 19, 2007, at 8:55 PM, David Chelimsky wrote:> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >> >> Wow. Thanks. You''ve opened up a whole new world of ruby for me. I >> had never heard of an UnboundMethod object before. > > Now the fun begins!!!!! > > Cheers, > David > >> >> I should have RTFM''ed before I was so quick on my reply. >> >> Thanks a bunch, >> >> Scott >> >> >> On Mar 19, 2007, at 6:59 PM, David Chelimsky wrote: >> >>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>>> >>>> >>>> But that doesn''t check that the methods are the same, does it? >>>> Doesn''t it only check if the values returned by the methods are >>>> equal >>>> (in this case, nil)? >>> >>> That''s not what I get from the docs: >>> >>> http://www.ruby-doc.org/core/classes/Module.html#M001682 >>> >>> Seems to me it''s an UnboundMethod object (or Method in the second >>> example I gave). >>> >>> WDYT? >>> >>> >>>> >>>> Scott >>>> >>>> >>>> On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote: >>>> >>>>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>>>>> >>>>>> I am completely baffled by this one - My guess is that there >>>>>> is no >>>>>> pure ruby way to do this - but how could I set up a spec to test >>>>>> that >>>>>> one method is an alias of another? >>>>> >>>>> class Foo >>>>> def bar >>>>> end >>>>> alias :baz :bar >>>>> end >>>>> >>>>> context "Foo class" do >>>>> specify "should use the same method for #baz as #bar" do >>>>> Foo.instance_method(:baz).should == Foo.instance_method(:bar) >>>>> end >>>>> end >>>>> >>>>> context "Foo instance" do >>>>> specify "should use the same method for #baz as #bar" do >>>>> foo = Foo.new >>>>> foo.method(:baz).should == foo.method(:bar) >>>>> end >>>>> end >>>>> >>>>> equal? won''t work because the resulting method isn''t the same >>>>> object, >>>>> but you''ll see that == fails when the implementations they >>>>> point to >>>>> are different. >>>>> >>>>> Hope that works for you. >>>>> >>>>> David >>>>> >>>>>> >>>>>> Thanks for any help, >>>>>> >>>>>> Scott >>>>>> >>>>>> _______________________________________________ >>>>>> 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
Well honestly I just wanted a method which could be called in the plural or singular, something like: column_name :a_col or columns_names :a_first_col, :a_second_col but I want it to be the same method, and I want it to work the same way. (namely to return an array or a hash, and/or possibly set an instance variable) That''s what led me to the idea in the first place, that I should test them in separate contexts, but assuring that they were indeed the same method in one of the contexts... Scott On Mar 20, 2007, at 1:45 AM, s.ross wrote:> This is cool, but I just gotta ask: Is this kind of a spec about > behavior or low-level testing? I thought the whole zen of the spec > thing was to describe desired behaviors programmatically. The notion > being that these behaviors would be relatively coarse grained and the > finer-grained (i.e., implementation details) would sort themselves > out as you fix failures. > > The whole appeal to me is that you write the specs without suggesting > too much about the implementation of the solution. What you''re > describing here appears to be tied intimately with the > implementation, so if you change that you break the spec, right? > > Just a thought :) > > > On Mar 19, 2007, at 8:55 PM, David Chelimsky wrote: > >> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>> >>> Wow. Thanks. You''ve opened up a whole new world of ruby for me. I >>> had never heard of an UnboundMethod object before. >> >> Now the fun begins!!!!! >> >> Cheers, >> David >> >>> >>> I should have RTFM''ed before I was so quick on my reply. >>> >>> Thanks a bunch, >>> >>> Scott >>> >>> >>> On Mar 19, 2007, at 6:59 PM, David Chelimsky wrote: >>> >>>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>>>> >>>>> >>>>> But that doesn''t check that the methods are the same, does it? >>>>> Doesn''t it only check if the values returned by the methods are >>>>> equal >>>>> (in this case, nil)? >>>> >>>> That''s not what I get from the docs: >>>> >>>> http://www.ruby-doc.org/core/classes/Module.html#M001682 >>>> >>>> Seems to me it''s an UnboundMethod object (or Method in the second >>>> example I gave). >>>> >>>> WDYT? >>>> >>>> >>>>> >>>>> Scott >>>>> >>>>> >>>>> On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote: >>>>> >>>>>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>>>>>> >>>>>>> I am completely baffled by this one - My guess is that there >>>>>>> is no >>>>>>> pure ruby way to do this - but how could I set up a spec to test >>>>>>> that >>>>>>> one method is an alias of another? >>>>>> >>>>>> class Foo >>>>>> def bar >>>>>> end >>>>>> alias :baz :bar >>>>>> end >>>>>> >>>>>> context "Foo class" do >>>>>> specify "should use the same method for #baz as #bar" do >>>>>> Foo.instance_method(:baz).should == Foo.instance_method(:bar) >>>>>> end >>>>>> end >>>>>> >>>>>> context "Foo instance" do >>>>>> specify "should use the same method for #baz as #bar" do >>>>>> foo = Foo.new >>>>>> foo.method(:baz).should == foo.method(:bar) >>>>>> end >>>>>> end >>>>>> >>>>>> equal? won''t work because the resulting method isn''t the same >>>>>> object, >>>>>> but you''ll see that == fails when the implementations they >>>>>> point to >>>>>> are different. >>>>>> >>>>>> Hope that works for you. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> Thanks for any help, >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 3/20/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > Well honestly I just wanted a method which could be called in the > plural or singular, something like: > > column_name :a_col > > or > > columns_names :a_first_col, :a_second_col > > but I want it to be the same method, and I want it to work the same > way. (namely to return an array or a hash, and/or possibly set an > instance variable) > > That''s what led me to the idea in the first place, that I should test > them in separate contexts, but assuring that they were indeed the > same method in one of the contexts...What benefit is there to knowing they are the same method, as long as they both do the same thing?> > Scott > > > > On Mar 20, 2007, at 1:45 AM, s.ross wrote: > > > This is cool, but I just gotta ask: Is this kind of a spec about > > behavior or low-level testing? I thought the whole zen of the spec > > thing was to describe desired behaviors programmatically. The notion > > being that these behaviors would be relatively coarse grained and the > > finer-grained (i.e., implementation details) would sort themselves > > out as you fix failures. > > > > The whole appeal to me is that you write the specs without suggesting > > too much about the implementation of the solution. What you''re > > describing here appears to be tied intimately with the > > implementation, so if you change that you break the spec, right? > > > > Just a thought :) > > > > > > On Mar 19, 2007, at 8:55 PM, David Chelimsky wrote: > > > >> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >>> > >>> Wow. Thanks. You''ve opened up a whole new world of ruby for me. I > >>> had never heard of an UnboundMethod object before. > >> > >> Now the fun begins!!!!! > >> > >> Cheers, > >> David > >> > >>> > >>> I should have RTFM''ed before I was so quick on my reply. > >>> > >>> Thanks a bunch, > >>> > >>> Scott > >>> > >>> > >>> On Mar 19, 2007, at 6:59 PM, David Chelimsky wrote: > >>> > >>>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >>>>> > >>>>> > >>>>> But that doesn''t check that the methods are the same, does it? > >>>>> Doesn''t it only check if the values returned by the methods are > >>>>> equal > >>>>> (in this case, nil)? > >>>> > >>>> That''s not what I get from the docs: > >>>> > >>>> http://www.ruby-doc.org/core/classes/Module.html#M001682 > >>>> > >>>> Seems to me it''s an UnboundMethod object (or Method in the second > >>>> example I gave). > >>>> > >>>> WDYT? > >>>> > >>>> > >>>>> > >>>>> Scott > >>>>> > >>>>> > >>>>> On Mar 19, 2007, at 6:48 PM, David Chelimsky wrote: > >>>>> > >>>>>> On 3/19/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > >>>>>>> > >>>>>>> I am completely baffled by this one - My guess is that there > >>>>>>> is no > >>>>>>> pure ruby way to do this - but how could I set up a spec to test > >>>>>>> that > >>>>>>> one method is an alias of another? > >>>>>> > >>>>>> class Foo > >>>>>> def bar > >>>>>> end > >>>>>> alias :baz :bar > >>>>>> end > >>>>>> > >>>>>> context "Foo class" do > >>>>>> specify "should use the same method for #baz as #bar" do > >>>>>> Foo.instance_method(:baz).should == Foo.instance_method(:bar) > >>>>>> end > >>>>>> end > >>>>>> > >>>>>> context "Foo instance" do > >>>>>> specify "should use the same method for #baz as #bar" do > >>>>>> foo = Foo.new > >>>>>> foo.method(:baz).should == foo.method(:bar) > >>>>>> end > >>>>>> end > >>>>>> > >>>>>> equal? won''t work because the resulting method isn''t the same > >>>>>> object, > >>>>>> but you''ll see that == fails when the implementations they > >>>>>> point to > >>>>>> are different. > >>>>>> > >>>>>> Hope that works for you. > >>>>>> > >>>>>> David > >>>>>> > >>>>>>> > >>>>>>> Thanks for any help, > >>>>>>> > >>>>>>> Scott > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > > > > _______________________________________________ > > 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 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote:> On 3/20/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > > > > Well honestly I just wanted a method which could be called in the > > plural or singular, something like: > > > > column_name :a_col > > > > or > > > > columns_names :a_first_col, :a_second_col > > > > but I want it to be the same method, and I want it to work the same > > way. (namely to return an array or a hash, and/or possibly set an > > instance variable) > > > > That''s what led me to the idea in the first place, that I should test > > them in separate contexts, but assuring that they were indeed the > > same method in one of the contexts... > > What benefit is there to knowing they are the same method, as long as > they both do the same thing?I''ve experienced a similar situation before. The reason I looked at testing that they are the same method is that it seemed more DRY to do that than to copy/paste the specs for that method and replace the name. WDYT? -Bryan
On 3/20/07, Bryan Helmkamp <bhelmkamp at gmail.com> wrote:> On 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote: > > On 3/20/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: > > > > > > Well honestly I just wanted a method which could be called in the > > > plural or singular, something like: > > > > > > column_name :a_col > > > > > > or > > > > > > columns_names :a_first_col, :a_second_col > > > > > > but I want it to be the same method, and I want it to work the same > > > way. (namely to return an array or a hash, and/or possibly set an > > > instance variable) > > > > > > That''s what led me to the idea in the first place, that I should test > > > them in separate contexts, but assuring that they were indeed the > > > same method in one of the contexts... > > > > What benefit is there to knowing they are the same method, as long as > > they both do the same thing? > > I''ve experienced a similar situation before. The reason I looked at > testing that they are the same method is that it seemed more DRY to do > that than to copy/paste the specs for that method and replace the > name. WDYT?That makes sense. Another way to keep the code DRY would be to wrap the example in a loop: (pardon the trunk syntax....) describe Thing do [:b, :c].each do |method| it "should do a when you send it #{method}" do #expect something.... Thing.new.send method end end end This way the same behaviour get specified for both methods, but there''s only one set of specs describing the behaviour. WDYT?> > -Bryan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Cool new Trunk syntax? Is there any rss feed where I can monitor the changes?
On 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote:> On 3/20/07, Bryan Helmkamp <bhelmkamp at gmail.com> wrote: > > I''ve experienced a similar situation before. The reason I looked at > > testing that they are the same method is that it seemed more DRY to do > > that than to copy/paste the specs for that method and replace the > > name. WDYT? > > That makes sense. Another way to keep the code DRY would be to wrap > the example in a loop: > > (pardon the trunk syntax....) > > describe Thing do > [:b, :c].each do |method| > it "should do a when you send it #{method}" do > #expect something.... > Thing.new.send method > end > end > end > > This way the same behaviour get specified for both methods, but > there''s only one set of specs describing the behaviour.I like that solution, David. I''ve used loops for defining specify block in some other places, and I''m happy with the results. Just wondering, if instead of having one Thing with two methods that are identical, you instead had two types of things (Foo and Bar) with one method that should behave the same for each, how would you go about specifying that? Would you write a high level custom matcher? Use a loop to create two context blocks? Or something else? -Bryan
Unless rubyforge makes one available that I don''t know about, I don''t think so. On 3/20/07, s.ross <cwdinfo at gmail.com> wrote:> Cool new Trunk syntax? Is there any rss feed where I can monitor the > changes? > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On 21/03/2007, at 10:47 AM, David Chelimsky wrote:> Unless rubyforge makes one available that I don''t know about, I > don''t think so. > > On 3/20/07, s.ross <cwdinfo at gmail.com> wrote: >> Cool new Trunk syntax? Is there any rss feed where I can monitor the >> changes?yep, thanks to our buddy chris-err-wanstrath: http:// subtlety.errtheblog.com/ -- tim
On Mar 20, 2007, at 12:52 PM, Bryan Helmkamp wrote:> On 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote: >> On 3/20/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote: >>> >>> Well honestly I just wanted a method which could be called in the >>> plural or singular, something like: >>> >>> column_name :a_col >>> >>> or >>> >>> columns_names :a_first_col, :a_second_col >>> >>> but I want it to be the same method, and I want it to work the same >>> way. (namely to return an array or a hash, and/or possibly set an >>> instance variable) >>> >>> That''s what led me to the idea in the first place, that I should >>> test >>> them in separate contexts, but assuring that they were indeed the >>> same method in one of the contexts... >> >> What benefit is there to knowing they are the same method, as long as >> they both do the same thing? > > I''ve experienced a similar situation before. The reason I looked at > testing that they are the same method is that it seemed more DRY to do > that than to copy/paste the specs for that method and replace the > name. WDYT?Actually I wasn''t going for DRY, specifically. I wanted it more for an annotation, or documentation to my code. Scott
On 3/20/07, Tim Lucas <t.lucas at toolmantim.com> wrote:> On 21/03/2007, at 10:47 AM, David Chelimsky wrote: > > > Unless rubyforge makes one available that I don''t know about, I > > don''t think so. > > > > On 3/20/07, s.ross <cwdinfo at gmail.com> wrote: > >> Cool new Trunk syntax? Is there any rss feed where I can monitor the > >> changes? > > yep, thanks to our buddy chris-err-wanstrath: http:// > subtlety.errtheblog.com/WOW! That is soooo cool. Thanks, David> > -- tim > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Thanks! This rocks. On Mar 20, 2007, at 4:59 PM, Tim Lucas wrote:> On 21/03/2007, at 10:47 AM, David Chelimsky wrote: > >> Unless rubyforge makes one available that I don''t know about, I >> don''t think so. >> >> On 3/20/07, s.ross <cwdinfo at gmail.com> wrote: >>> Cool new Trunk syntax? Is there any rss feed where I can monitor the >>> changes? > > yep, thanks to our buddy chris-err-wanstrath: http:// > subtlety.errtheblog.com/ > > -- tim > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
"Bryan Helmkamp" <bhelmkamp at gmail.com> writes:> On 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote: >> On 3/20/07, Bryan Helmkamp <bhelmkamp at gmail.com> wrote: >> > I''ve experienced a similar situation before. The reason I looked at >> > testing that they are the same method is that it seemed more DRY to do >> > that than to copy/paste the specs for that method and replace the >> > name. WDYT? >> >> That makes sense. Another way to keep the code DRY would be to wrap >> the example in a loop: >> >> (pardon the trunk syntax....) >> >> describe Thing do >> [:b, :c].each do |method| >> it "should do a when you send it #{method}" do >> #expect something.... >> Thing.new.send method >> end >> end >> end >> >> This way the same behaviour get specified for both methods, but >> there''s only one set of specs describing the behaviour. > > I like that solution, David. I''ve used loops for defining specify > block in some other places, and I''m happy with the results. Just > wondering, if instead of having one Thing with two methods that are > identical, you instead had two types of things (Foo and Bar) with one > method that should behave the same for each, how would you go about > specifying that? Would you write a high level custom matcher? Use a > loop to create two context blocks? Or something else?We have this exact problem, and the solution I was kicking around was: Module Foo def same; end end Module Bar def same; end end context Foo, Bar, "Foo and Bar" do setup do same end end where ''context'' would accept a list of modules to include, and generate a new context for each. -bob
On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:> "Bryan Helmkamp" <bhelmkamp at gmail.com> writes: > > On 3/20/07, David Chelimsky <dchelimsky at gmail.com> wrote: > >> On 3/20/07, Bryan Helmkamp <bhelmkamp at gmail.com> wrote: > >> > I''ve experienced a similar situation before. The reason I looked at > >> > testing that they are the same method is that it seemed more DRY to do > >> > that than to copy/paste the specs for that method and replace the > >> > name. WDYT? > >> > >> That makes sense. Another way to keep the code DRY would be to wrap > >> the example in a loop: > >> > >> (pardon the trunk syntax....) > >> > >> describe Thing do > >> [:b, :c].each do |method| > >> it "should do a when you send it #{method}" do > >> #expect something.... > >> Thing.new.send method > >> end > >> end > >> end > >> > >> This way the same behaviour get specified for both methods, but > >> there''s only one set of specs describing the behaviour. > > > > I like that solution, David. I''ve used loops for defining specify > > block in some other places, and I''m happy with the results. Just > > wondering, if instead of having one Thing with two methods that are > > identical, you instead had two types of things (Foo and Bar) with one > > method that should behave the same for each, how would you go about > > specifying that? Would you write a high level custom matcher? Use a > > loop to create two context blocks? Or something else? > > We have this exact problem, and the solution I was kicking around was: > > Module Foo > def same; end > end > > Module Bar > def same; end > end > > context Foo, Bar, "Foo and Bar" do > setup do > same > end > end > > where ''context'' would accept a list of modules to include, and > generate a new context for each.That''s a really interesting idea. If Foo and Bar have different initializers, there needs to be a separate setup for each. The first thing that comes to my mind is this: describe Foo, Bar, "#some_method" do setup Foo do @obj = Foo.new(...) end setup Bar do @obj = Bar.new(...) end it "should do something" do ... end end This could match up the module w/ the correct setup block and output this: Foo#some_method - should do something Bar#some_method - should do something The thing I don''t like about this is that if you have 10 classes that implement one method, each in its own way, the output could start to get quite verbose, with things like: Foo#a - should blah Foo#b - should other blah etc Now we could solve that by storing all of the output and grouping it together by Class, so you would still get: Foo#a - should blah - should other blah I can see this becoming a problem in terms of finding the code for a given example. Perhaps we can have a CL switch that adds filenames and/or line numbers to the output. Seems like this could spiral into a lot of complexity. But it IS interesting. Thoughts?> > -bob > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
"David Chelimsky" <dchelimsky at gmail.com> writes:> On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote: >> "Bryan Helmkamp" <bhelmkamp at gmail.com> writes: >> > I like that solution, David. I''ve used loops for defining specify >> > block in some other places, and I''m happy with the results. Just >> > wondering, if instead of having one Thing with two methods that are >> > identical, you instead had two types of things (Foo and Bar) with one >> > method that should behave the same for each, how would you go about >> > specifying that? Would you write a high level custom matcher? Use a >> > loop to create two context blocks? Or something else? >> >> We have this exact problem, and the solution I was kicking around was: >> >> Module Foo >> def same; end >> end >> >> Module Bar >> def same; end >> end >> >> context Foo, Bar, "Foo and Bar" do >> setup do >> same >> end >> end >> >> where ''context'' would accept a list of modules to include, and >> generate a new context for each. > > That''s a really interesting idea. If Foo and Bar have different > initializers, there needs to be a separate setup for each. The first > thing that comes to my mind is this: > > describe Foo, Bar, "#some_method" do > setup Foo do > @obj = Foo.new(...) > end > > setup Bar do > @obj = Bar.new(...) > end > > it "should do something" do > ... > end > end > > This could match up the module w/ the correct setup block and output this: > > Foo#some_method > - should do something > > Bar#some_method > - should do something > > The thing I don''t like about this is that if you have 10 classes that > implement one method, each in its own way, the output could start to > get quite verbose, with things like: > > Foo#a > - should blah > > Foo#b > - should other blah > > etc > > Now we could solve that by storing all of the output and grouping it > together by Class, so you would still get: > > Foo#a > - should blah > - should other blah > > I can see this becoming a problem in terms of finding the code for a > given example. Perhaps we can have a CL switch that adds filenames > and/or line numbers to the output. Seems like this could spiral into a > lot of complexity. But it IS interesting. > > Thoughts?[ I''m still thinking in context/specify. ] David, your suggestion does answer Bryan''s scenario, "you instead had two types of things (Foo and Bar) with one method that should behave the same for each" It is an interesting approach to testing a common behavior between two classes. But what about factoring the specify into a module: module Common specify "..." end then include that into the context? I guess I should have been more specific in my example. My take on it was having modules that contained some helper methods, with the same name, that would be shared across contexts. We are using rspec mostly for defining acceptance tests. We have a system that has multiple "editions", where the behavior of the editions is largely the same. Let''s call these editions Large and Small. I would like to write a context that defines the common behavior of all editions, but have setup create the correct edition, for example: module Large def create; end end module Small def create; end end context Large, Small, "All editions" do setup do @system = create end specify ... end It''s kind of a dependency injection for contexts. - Bob
On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:> "David Chelimsky" <dchelimsky at gmail.com> writes: > > On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote: > >> "Bryan Helmkamp" <bhelmkamp at gmail.com> writes: > >> > I like that solution, David. I''ve used loops for defining specify > >> > block in some other places, and I''m happy with the results. Just > >> > wondering, if instead of having one Thing with two methods that are > >> > identical, you instead had two types of things (Foo and Bar) with one > >> > method that should behave the same for each, how would you go about > >> > specifying that? Would you write a high level custom matcher? Use a > >> > loop to create two context blocks? Or something else? > >> > >> We have this exact problem, and the solution I was kicking around was: > >> > >> Module Foo > >> def same; end > >> end > >> > >> Module Bar > >> def same; end > >> end > >> > >> context Foo, Bar, "Foo and Bar" do > >> setup do > >> same > >> end > >> end > >> > >> where ''context'' would accept a list of modules to include, and > >> generate a new context for each. > > > > That''s a really interesting idea. If Foo and Bar have different > > initializers, there needs to be a separate setup for each. The first > > thing that comes to my mind is this: > > > > describe Foo, Bar, "#some_method" do > > setup Foo do > > @obj = Foo.new(...) > > end > > > > setup Bar do > > @obj = Bar.new(...) > > end > > > > it "should do something" do > > ... > > end > > end > > > > This could match up the module w/ the correct setup block and output this: > > > > Foo#some_method > > - should do something > > > > Bar#some_method > > - should do something > > > > The thing I don''t like about this is that if you have 10 classes that > > implement one method, each in its own way, the output could start to > > get quite verbose, with things like: > > > > Foo#a > > - should blah > > > > Foo#b > > - should other blah > > > > etc > > > > Now we could solve that by storing all of the output and grouping it > > together by Class, so you would still get: > > > > Foo#a > > - should blah > > - should other blah > > > > I can see this becoming a problem in terms of finding the code for a > > given example. Perhaps we can have a CL switch that adds filenames > > and/or line numbers to the output. Seems like this could spiral into a > > lot of complexity. But it IS interesting. > > > > Thoughts? > > [ I''m still thinking in context/specify. ] > > David, your suggestion does answer Bryan''s scenario, > > "you instead had two types of things (Foo and Bar) with one method > that should behave the same for each" > > It is an interesting approach to testing a common behavior between two > classes. But what about factoring the specify into a module: > > module Common > specify "..." > end > > then include that into the context?The problem there is that we''d have to add #specify to Module, which I''m hesitant to do. How about this (using "it" and Examples instead of "specify"): module EditionExamples < SharedExampleGroup it "should " do .. end end describe LargeEdition do include EditionExamples setup do ... end end describe SmallEdition do include EditionExamples setup do ... end end That make sense?> > I guess I should have been more specific in my example. > > My take on it was having modules that contained some helper methods, > with the same name, that would be shared across contexts. > > We are using rspec mostly for defining acceptance tests. We have > a system that has multiple "editions", where the behavior of the > editions is largely the same. Let''s call these editions Large and > Small. > > I would like to write a context that defines the common behavior of > all editions, but have setup create the correct edition, for example: > > module Large > def create; end > end > > module Small > def create; end > end > > context Large, Small, "All editions" do > setup do > @system = create > end > specify ... > end > > It''s kind of a dependency injection for contexts. > > > - Bob > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
"David Chelimsky" <dchelimsky at gmail.com> writes:> On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote: >> >> [ I''m still thinking in context/specify. ] >> >> David, your suggestion does answer Bryan''s scenario, >> >> "you instead had two types of things (Foo and Bar) with one method >> that should behave the same for each" >> >> It is an interesting approach to testing a common behavior between two >> classes. But what about factoring the specify into a module: >> >> module Common >> specify "..." >> end >> >> then include that into the context? > > The problem there is that we''d have to add #specify to Module, which > I''m hesitant to do. How about this (using "it" and Examples instead of > "specify"): > > module EditionExamples < SharedExampleGroup > it "should " do > .. > end > end > > describe LargeEdition do > include EditionExamples > setup do > ... > end > end > > describe SmallEdition do > include EditionExamples > setup do > ... > end > end > > That make sense?Sure does, except, can you have modules subclass?> module EditionExamples < SharedExampleGroupInstead of factoring out the setup bits and having a common behavior, factor out the common behavior and have the #describe be the thing we are defining, which makes more sense. That fells right. I''d be all for adding specify/it to Module. *or* rspec, through #describe, is creating classes on the fly. Could you have something that defines common behavior that writes Modules on the fly? describe_common AllEditions do it "should" do end end describe "LargeEdition" do include AllEditions setup ... end describe "SmallEdition" do include AllEditions setup ... end - Bob
On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:> "David Chelimsky" <dchelimsky at gmail.com> writes: > > On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote: > >> > >> [ I''m still thinking in context/specify. ] > >> > >> David, your suggestion does answer Bryan''s scenario, > >> > >> "you instead had two types of things (Foo and Bar) with one method > >> that should behave the same for each" > >> > >> It is an interesting approach to testing a common behavior between two > >> classes. But what about factoring the specify into a module: > >> > >> module Common > >> specify "..." > >> end > >> > >> then include that into the context? > > > > The problem there is that we''d have to add #specify to Module, which > > I''m hesitant to do. How about this (using "it" and Examples instead of > > "specify"): > > > > module EditionExamples < SharedExampleGroup > > it "should " do > > .. > > end > > end > > > > describe LargeEdition do > > include EditionExamples > > setup do > > ... > > end > > end > > > > describe SmallEdition do > > include EditionExamples > > setup do > > ... > > end > > end > > > > That make sense? > > Sure does, except, can you have modules subclass? > > > module EditionExamples < SharedExampleGroup > > Instead of factoring out the setup bits and having a common behavior, > factor out the common behavior and have the #describe be > the thing we are defining, which makes more sense. That fells right. > > I''d be all for adding specify/it to Module. > > *or* > > rspec, through #describe, is creating classes on the fly. Could you > have something that defines common behavior that writes Modules on the > fly? > > describe_common AllEditions do > it "should" do > end > end > > describe "LargeEdition" do > include AllEditions > setup ... > end > > describe "SmallEdition" do > include AllEditions > setup ... > endThat''s interesting too, though I''d hate to corrupt the beauty of describe w/ _common. How about: describe AllEditions, :shared => true do it "should" do end end etc..> > - Bob > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
"David Chelimsky" <dchelimsky at gmail.com> writes:> That''s interesting too, though I''d hate to corrupt the beauty of > describe w/ _common. How about: > > describe AllEditions, :shared => true do > it "should" do > end > endI like that very much. - Bob