David Chelimsky
2007-Apr-28 14:39 UTC
[rspec-users] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour
Hi all - I''ve applied (to trunk) Bob Cotton''s patch which supports shared behaviours (link to tracker below). I''m still toying w/ names, so please be aware that until this is released w/ 0.9 it should be considered experimental and there will NOT be translation support for it. It will definitely be included in some form - just the names (specifically it_should_behave_like) might change. That said, I encourage all you trunksters to grab the latest trunk and give this feature a roll. I think it solves the problem of duplication across behaviours very nicely. And please provide feedback. If you have any issues with this I want to know about them before we release 0.9 (which is coming VERY soon). Cheers, David On 4/28/07, noreply at rubyforge.org <noreply at rubyforge.org> wrote:> Patches item #9605, was opened at 2007-03-27 04:08 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > >Category: runner module > Group: None > >Status: Closed > >Resolution: Accepted > Priority: 3 > Submitted By: Bob Cotton (bcotton) > >Assigned to: David Chelimsky (dchelimsky) > Summary: Patch for ER 9472, shared behaviour > > Initial Comment: > I chose behaves_as, as the inclusion method. > > I don''t like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. > > > > Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. > > > > There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! > > > > -Bob > > ---------------------------------------------------------------------- > > >Comment By: David Chelimsky (dchelimsky) > Date: 2007-04-28 14:34 > > Message: > Applied to trunk rev 1820. > > > > Nice work Bob - thanks! > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-04-02 14:11 > > Message: > Newest version of the patch attached. > > ---------------------------------------------------------------------- > > Comment By: Aslak Helles?y (aslak_hellesoy) > Date: 2007-03-28 11:11 > > Message: > I haven''t had time to look into this in detail, but it looks interesting. Right now we''re trying to get 0.9 out the door, and we''re reluctant to add new features before 0.9 is released. > > > > Let''s revisit this post 0.9 > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-03-27 12:12 > > Message: > Missed the checkbox. Sorry. > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-03-27 12:11 > > Message: > One more thing, rcov is at 100%, but I can''t get pre_commit > > to run. It either runs out of memory, or the stack is too deep. > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2007-03-27 04:16 > > Message: > File please. > > ---------------------------------------------------------------------- > > Comment By: David Chelimsky (dchelimsky) > Date: 2007-03-27 04:15 > > Message: > Hi Bob - I''ll take a look at this tomorrow. Thanks. > > > > FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. > > ---------------------------------------------------------------------- > > Comment By: Bob Cotton (bcotton) > Date: 2007-03-27 04:10 > > Message: > One more thing, rcov is at 100%, but I can''t get pre_commit > > to run. It either runs out of memory, or the stack is too deep. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 >
David Chelimsky
2007-Apr-28 15:58 UTC
[rspec-users] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour
Sorry for the noise - I applied this patch after some time had passed since it was submitted. I got all the specs passing and assumed all was OK, but I just tried this outside of RSpec''s own environment and it doesn''t work so I must have botched something up. I''ll get this working in the next couple of days and follow up on both lists when its ready to try for real. Cheers, David On 4/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:> Hi all - I''ve applied (to trunk) Bob Cotton''s patch which supports > shared behaviours (link to tracker below). > > I''m still toying w/ names, so please be aware that until this is > released w/ 0.9 it should be considered experimental and there will > NOT be translation support for it. It will definitely be included in > some form - just the names (specifically it_should_behave_like) might > change. > > That said, I encourage all you trunksters to grab the latest trunk and > give this feature a roll. I think it solves the problem of duplication > across behaviours very nicely. And please provide feedback. If you > have any issues with this I want to know about them before we release > 0.9 (which is coming VERY soon). > > Cheers, > David > > On 4/28/07, noreply at rubyforge.org <noreply at rubyforge.org> wrote: > > Patches item #9605, was opened at 2007-03-27 04:08 > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > > >Category: runner module > > Group: None > > >Status: Closed > > >Resolution: Accepted > > Priority: 3 > > Submitted By: Bob Cotton (bcotton) > > >Assigned to: David Chelimsky (dchelimsky) > > Summary: Patch for ER 9472, shared behaviour > > > > Initial Comment: > > I chose behaves_as, as the inclusion method. > > > > I don''t like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. > > > > > > > > Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. > > > > > > > > There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! > > > > > > > > -Bob > > > > ---------------------------------------------------------------------- > > > > >Comment By: David Chelimsky (dchelimsky) > > Date: 2007-04-28 14:34 > > > > Message: > > Applied to trunk rev 1820. > > > > > > > > Nice work Bob - thanks! > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-04-02 14:11 > > > > Message: > > Newest version of the patch attached. > > > > ---------------------------------------------------------------------- > > > > Comment By: Aslak Helles?y (aslak_hellesoy) > > Date: 2007-03-28 11:11 > > > > Message: > > I haven''t had time to look into this in detail, but it looks interesting. Right now we''re trying to get 0.9 out the door, and we''re reluctant to add new features before 0.9 is released. > > > > > > > > Let''s revisit this post 0.9 > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-03-27 12:12 > > > > Message: > > Missed the checkbox. Sorry. > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-03-27 12:11 > > > > Message: > > One more thing, rcov is at 100%, but I can''t get pre_commit > > > > to run. It either runs out of memory, or the stack is too deep. > > > > ---------------------------------------------------------------------- > > > > Comment By: David Chelimsky (dchelimsky) > > Date: 2007-03-27 04:16 > > > > Message: > > File please. > > > > ---------------------------------------------------------------------- > > > > Comment By: David Chelimsky (dchelimsky) > > Date: 2007-03-27 04:15 > > > > Message: > > Hi Bob - I''ll take a look at this tomorrow. Thanks. > > > > > > > > FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. > > > > ---------------------------------------------------------------------- > > > > Comment By: Bob Cotton (bcotton) > > Date: 2007-03-27 04:10 > > > > Message: > > One more thing, rcov is at 100%, but I can''t get pre_commit > > > > to run. It either runs out of memory, or the stack is too deep. > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > >
David Chelimsky
2007-Apr-28 21:21 UTC
[rspec-users] [ rspec-Patches-9605 ] Patch for ER 9472, shared behaviour
OK - this is actually working now. Check out rev 1825 (or later). Take a peek at examples/shared_behaviours_example.rb to see how to use it. Cheers, David On 4/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:> Sorry for the noise - I applied this patch after some time had passed > since it was submitted. I got all the specs passing and assumed all > was OK, but I just tried this outside of RSpec''s own environment and > it doesn''t work so I must have botched something up. > > I''ll get this working in the next couple of days and follow up on both > lists when its ready to try for real. > > Cheers, > David > > On 4/28/07, David Chelimsky <dchelimsky at gmail.com> wrote: > > Hi all - I''ve applied (to trunk) Bob Cotton''s patch which supports > > shared behaviours (link to tracker below). > > > > I''m still toying w/ names, so please be aware that until this is > > released w/ 0.9 it should be considered experimental and there will > > NOT be translation support for it. It will definitely be included in > > some form - just the names (specifically it_should_behave_like) might > > change. > > > > That said, I encourage all you trunksters to grab the latest trunk and > > give this feature a roll. I think it solves the problem of duplication > > across behaviours very nicely. And please provide feedback. If you > > have any issues with this I want to know about them before we release > > 0.9 (which is coming VERY soon). > > > > Cheers, > > David > > > > On 4/28/07, noreply at rubyforge.org <noreply at rubyforge.org> wrote: > > > Patches item #9605, was opened at 2007-03-27 04:08 > > > You can respond by visiting: > > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > > > > >Category: runner module > > > Group: None > > > >Status: Closed > > > >Resolution: Accepted > > > Priority: 3 > > > Submitted By: Bob Cotton (bcotton) > > > >Assigned to: David Chelimsky (dchelimsky) > > > Summary: Patch for ER 9472, shared behaviour > > > > > > Initial Comment: > > > I chose behaves_as, as the inclusion method. > > > > > > I don''t like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad. > > > > > > > > > > > > Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another. > > > > > > > > > > > > There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors! > > > > > > > > > > > > -Bob > > > > > > ---------------------------------------------------------------------- > > > > > > >Comment By: David Chelimsky (dchelimsky) > > > Date: 2007-04-28 14:34 > > > > > > Message: > > > Applied to trunk rev 1820. > > > > > > > > > > > > Nice work Bob - thanks! > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-04-02 14:11 > > > > > > Message: > > > Newest version of the patch attached. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Aslak Helles?y (aslak_hellesoy) > > > Date: 2007-03-28 11:11 > > > > > > Message: > > > I haven''t had time to look into this in detail, but it looks interesting. Right now we''re trying to get 0.9 out the door, and we''re reluctant to add new features before 0.9 is released. > > > > > > > > > > > > Let''s revisit this post 0.9 > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-03-27 12:12 > > > > > > Message: > > > Missed the checkbox. Sorry. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-03-27 12:11 > > > > > > Message: > > > One more thing, rcov is at 100%, but I can''t get pre_commit > > > > > > to run. It either runs out of memory, or the stack is too deep. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: David Chelimsky (dchelimsky) > > > Date: 2007-03-27 04:16 > > > > > > Message: > > > File please. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: David Chelimsky (dchelimsky) > > > Date: 2007-03-27 04:15 > > > > > > Message: > > > Hi Bob - I''ll take a look at this tomorrow. Thanks. > > > > > > > > > > > > FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now. > > > > > > ---------------------------------------------------------------------- > > > > > > Comment By: Bob Cotton (bcotton) > > > Date: 2007-03-27 04:10 > > > > > > Message: > > > One more thing, rcov is at 100%, but I can''t get pre_commit > > > > > > to run. It either runs out of memory, or the stack is too deep. > > > > > > ---------------------------------------------------------------------- > > > > > > You can respond by visiting: > > > http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9605&group_id=797 > > > > > >
When mocking for an update method, I''m using this code.
@mock_setting = mock("setting")
Setting.should_receive(:find).once.and_return(@mock_setting)
@mock_setting.stub!(:save).and_return(false)
All well and good, as it''s supposed to generate a failed update.
However, the
<%= error_messages_for ''setting'' %>
wants a receiver for errors. Has anyone stubbed errors? The AR errors
object has to respond to a bunch of stuff and I wanted to find out if
someone had already done this (or if it''s a dumb idea).
Thanks,
Look for mock_model (in the plugin examples???) and/or google for ''making a mockery of ActiveRecord''. Hope this helps, Jerry s.ross wrote:> When mocking for an update method, I''m using this code. > > @mock_setting = mock("setting") > Setting.should_receive(:find).once.and_return(@mock_setting) > @mock_setting.stub!(:save).and_return(false) > > All well and good, as it''s supposed to generate a failed update. > However, the > > <%= error_messages_for ''setting'' %> > > wants a receiver for errors. Has anyone stubbed errors? The AR errors > object has to respond to a bunch of stuff and I wanted to find out if > someone had already done this (or if it''s a dumb idea). > > Thanks, > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Absolutely and totally helpful. What I''m missing is the je ne sais
quois about how mock_model works. I''d be happy to submit a doc patch
with an example if I could just get one :)
Here''s what I''m doing and tell me if my approach is haywire or
I''m
misunderstanding:
# the spec
it "should fail with POST and bad data"
mock_model Setting do |m| # seems mock_model now takes a
classname and not a symbol
m.should_receive(:find).once.and_return(@setting)
add_stubs(m, :save => false) # this can go into the second param
to mock_model, I guess
end
puts "for debugging purposes, save should result in false"
POST :update, :id => 1, :setting => {:setting_name =>
''first_new_setting'', :setting_value =>
''first_new_value'', :setting_type =>
''string''}
response_should be_success # because success renders action
''edit''
and sets a 200
end
# the controller
def update
@setting = Setting.find(params[:id])
puts "setting is #{@setting.save}"
# ...
end
What I''m seeing from the puts statements is:
for debugging purposes, save should result in false
setting is true
What am I missing about how this should work?
Thanks
Steve
On Apr 29, 2007, at 2:15 AM, Jerry West wrote:
> Look for mock_model (in the plugin examples???) and/or google for
> ''making a mockery of ActiveRecord''.
>
> Hope this helps,
> Jerry
>
> s.ross wrote:
>> When mocking for an update method, I''m using this code.
>>
>> @mock_setting = mock("setting")
>> Setting.should_receive(:find).once.and_return(@mock_setting)
>> @mock_setting.stub!(:save).and_return(false)
>>
>> All well and good, as it''s supposed to generate a failed
update.
>> However, the
>>
>> <%= error_messages_for ''setting'' %>
>>
>> wants a receiver for errors. Has anyone stubbed errors? The AR errors
>> object has to respond to a bunch of stuff and I wanted to find out if
>> someone had already done this (or if it''s a dumb idea).
>>
>> Thanks,
>> _______________________________________________
>> 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
Steve, I''m not at my desk, and can''t remember seeing #add_stubs before, though I can guess what it does. However, you seem to be using the parameter m yielded by mock_model as both the class (model) and the instance. If m is the class then the #should_receive(:find) will work as expected. But if so, does that mean #add_stubs is putting the stub for save on Setting (the class) and not @setting? I would make the expectation explicit: @setting.should_receive(:save).and_return(false). If that works check to see what mock_model is yielding (class or instance) and that add_stubs does what you think it does. If the expectation on @setting doesn''t make any difference, then I''m stumped without spending much more time on this (it''s nearly 1am here, I *really* should not be doing this!). Best wishes, Jerry s.ross wrote:> Absolutely and totally helpful. What I''m missing is the je ne sais > quois about how mock_model works. I''d be happy to submit a doc patch > with an example if I could just get one :) > > Here''s what I''m doing and tell me if my approach is haywire or I''m > misunderstanding: > > # the spec > > it "should fail with POST and bad data" > mock_model Setting do |m| # seems mock_model now takes a > classname and not a symbol > m.should_receive(:find).once.and_return(@setting) > add_stubs(m, :save => false) # this can go into the second param > to mock_model, I guess > end > > puts "for debugging purposes, save should result in false" > POST :update, :id => 1, :setting => {:setting_name => > ''first_new_setting'', :setting_value => > ''first_new_value'', :setting_type => ''string''} > response_should be_success # because success renders action ''edit'' > and sets a 200 > end > > # the controller > > def update > @setting = Setting.find(params[:id]) > puts "setting is #{@setting.save}" > # ... > end > > > What I''m seeing from the puts statements is: > > for debugging purposes, save should result in false > setting is true > > > What am I missing about how this should work? > > Thanks > > Steve
Here''s what I wound up doing:
setup do
@countable = mock(''countable'')
@countable.stub!(:count).and_return(1)
@countable.stub!(:full_messages).and_return([''a
message''])
@setting = mock_model Setting do |m|
m.stub!(:save).and_return(true)
m.stub!(:errors).and_return(@countable)
m.stub!(:setting_name).and_return(''first_name'')
m.stub!(:setting_value).and_return(''first_value'')
m.stub!(:setting_type).and_return(''first_type'')
end
end
That solves the original problem of the view requesting error
messages and barfing and also cleans up the code a lot.
Thanks!
On Apr 29, 2007, at 5:01 PM, Jerry West wrote:
> Steve,
>
> I''m not at my desk, and can''t remember seeing #add_stubs
before,
> though
> I can guess what it does. However, you seem to be using the
> parameter m
> yielded by mock_model as both the class (model) and the instance.
> If m
> is the class then the #should_receive(:find) will work as
> expected. But
> if so, does that mean #add_stubs is putting the stub for save on
> Setting
> (the class) and not @setting?
>
> I would make the expectation explicit:
> @setting.should_receive(:save).and_return(false). If that works check
> to see what mock_model is yielding (class or instance) and that
> add_stubs does what you think it does.
>
> If the expectation on @setting doesn''t make any difference, then
I''m
> stumped without spending much more time on this (it''s nearly 1am
> here, I
> *really* should not be doing this!).
>
> Best wishes,
> Jerry
>
>
> s.ross wrote:
>> Absolutely and totally helpful. What I''m missing is the je ne
sais
>> quois about how mock_model works. I''d be happy to submit a doc
patch
>> with an example if I could just get one :)
>>
>> Here''s what I''m doing and tell me if my approach is
haywire or I''m
>> misunderstanding:
>>
>> # the spec
>>
>> it "should fail with POST and bad data"
>> mock_model Setting do |m| # seems mock_model now takes a
>> classname and not a symbol
>> m.should_receive(:find).once.and_return(@setting)
>> add_stubs(m, :save => false) # this can go into the second
param
>> to mock_model, I guess
>> end
>>
>> puts "for debugging purposes, save should result in false"
>> POST :update, :id => 1, :setting => {:setting_name =>
>> ''first_new_setting'', :setting_value =>
>> ''first_new_value'', :setting_type =>
''string''}
>> response_should be_success # because success renders action
''edit''
>> and sets a 200
>> end
>>
>> # the controller
>>
>> def update
>> @setting = Setting.find(params[:id])
>> puts "setting is #{@setting.save}"
>> # ...
>> end
>>
>>
>> What I''m seeing from the puts statements is:
>>
>> for debugging purposes, save should result in false
>> setting is true
>>
>>
>> What am I missing about how this should work?
>>
>> Thanks
>>
>> Steve
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users