RSpec''s changelog says that in version 1.2.5: "also alias_method :stub, :stub!, so you can stub with less bang" which I''ve been taking advantage of a lot. However, I just ran into a situation where using #stub caused an error to occur, and changing to #stub! caused the error the disappear. Any idea what''s going on? http://codepad.org/P2uIlJVj Thanks, Nick -- Posted via http://www.ruby-forum.com/.
I''ve never heard of CurbFu, but according to http://github.com/gdi/curb-fu/blob/master/lib/curb-fu.rb#L43 it defines a stub method already. So you''re hitting that one, which expects two arguments. stub! goes to RSpec''s mocking framework. Pat On Mar 19, 2010, at 10:00 AM, Nick Hoffman wrote:> RSpec''s changelog says that in version 1.2.5: > > "also alias_method :stub, :stub!, so you can stub with less bang" > > which I''ve been taking advantage of a lot. > > However, I just ran into a situation where using #stub caused an error > to occur, and changing to #stub! caused the error the disappear. > > Any idea what''s going on? > > http://codepad.org/P2uIlJVj > > Thanks, > Nick > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Pat Maddox wrote:> I''ve never heard of CurbFu, but according to > http://github.com/gdi/curb-fu/blob/master/lib/curb-fu.rb#L43 it defines > a stub method already. So you''re hitting that one, which expects two > arguments. stub! goes to RSpec''s mocking framework. > > PatGood catch! Thanks, Pat. -- Posted via http://www.ruby-forum.com/.
On Mar 19, 2010, at 1:27 PM, Nick Hoffman wrote:> Pat Maddox wrote: >> I''ve never heard of CurbFu, but according to >> http://github.com/gdi/curb-fu/blob/master/lib/curb-fu.rb#L43 it defines >> a stub method already. So you''re hitting that one, which expects two >> arguments. stub! goes to RSpec''s mocking framework. >> >> Pat > > Good catch! Thanks, Pat.This presents an interesting dilemma, in that I (now not so) secretly plan to deprecate and remove stub(). I also plan to offer up a mode in which you don''t get stub and should_receive added to every object, but instead have to wrap each object you want to set stubs/message expectations on. i.e. double(Foo).stub(:bar) { return value } This is how flexmock works, and it helps to avoid problems exactly like the one you''ve uncovered. I guess these two changes will need to ship together :) Cheers, David
Hi,
I have this in my controller action:
from_address = Setting.find_by_name("shipping_from_address").address
and my spec fails:
NoMethodError in ''Admin::ShippingLabelsController should render a pdf
file''
undefined method `address'' for nil:NilClass
yet in the console I can do:
>> Setting.find_by_name("shipping_from_address").address
=> #<Address id: 1970, label: .... etc>
and I get the address-- so I don''t understand why it''s failing
in the spec.. ?
...
Also, if I want to test that I am getting a pdf back, how is the best way to do
that?
I was doing:
controller:
respond_to do |format|
format.pdf do
render :template => ''admin/contacts/shipping_label''
end
spec:
def do_get
get :create, :format => :pdf
end
it "should render a pdf file" do
do_get
response.should render_template("admin/contacts/shipping_label")
end
-- but that gives me:
''Admin::ShippingLabelsController should render a pdf file''
FAILED
expected "admin/contacts/shipping_label", got nil
/Users/patrick/coding/rails/matthew/spec/controllers/admin/shipping_labels_controller_spec.rb:11:
thanks...
Patrick J. Collins
http://collinatorstudios.com
Patrick Collins wrote:> Hi, > > I have this in my controller action: > > from_address = Setting.find_by_name("shipping_from_address").address > > and my spec fails: > > NoMethodError in ''Admin::ShippingLabelsController should render a pdf > file'' > undefined method `address'' for nil:NilClass > > ...snip...Patrick, please create a new thread for this, since it doesn''t have anything to do with the current topic. -- Posted via http://www.ruby-forum.com/.
> Patrick, please create a new thread for this, since it doesn''t have > anything to do with the current topic.Wow that is weird.. I replied to the previous thread in my email client but removed the subject-- as I assumed that was what kept things associated with threads; there was no other text in the email pertaining to this thread, and the address was the generic rspec- users at rubyforge.org... So I don''t quite understand why my post was thrown under this topic.. Oh well, sorry about that and I will repost. -patrick
patrick99e99 wrote:>> Patrick, please create a new thread for this, since it doesn''t have >> anything to do with the current topic. > > Wow that is weird.. I replied to the previous thread in my email > client but removed the subject-- as I assumed that was what kept > things associated with threads; there was no other text in the email > pertaining to this thread, and the address was the generic rspec- > users at rubyforge.org... So I don''t quite understand why my post was > thrown under this topic.. > > Oh well, sorry about that and I will repost. > > -patrickNo worries, mate. There''s an email header that identifies which thread a given post belongs to. If you reply to a post, your reply will inherit that header, and thus be associated with the thread. Cheers, Nick -- Posted via http://www.ruby-forum.com/.
On Fri, Mar 19, 2010 at 1:39 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Mar 19, 2010, at 1:27 PM, Nick Hoffman wrote: > >> Pat Maddox wrote: >>> I''ve never heard of CurbFu, but according to >>> http://github.com/gdi/curb-fu/blob/master/lib/curb-fu.rb#L43 it defines >>> a stub method already. ?So you''re hitting that one, which expects two >>> arguments. ?stub! goes to RSpec''s mocking framework. >>> >>> Pat >> >> Good catch! Thanks, Pat. > > > This presents an interesting dilemma, in that I (now not so) secretly plan to deprecate and remove stub().D''oh - stub!() - that''s the one I plan to remove. So we would only have stub(). There is no need to have both, since they do the same thing, and there is nothing particularly bangy about the stub method.> > I also plan to offer up a mode in which you don''t get stub and should_receive added to every object, but instead have to wrap each object you want to set stubs/message expectations on. i.e. > > double(Foo).stub(:bar) { return value } > > This is how flexmock works, and it helps to avoid problems exactly like the one you''ve uncovered. > > I guess these two changes will need to ship together :) > > Cheers, > David