Stub vs stub!

Testing RSpec
1

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

2

I’ve never heard of CurbFu, but according to
curb-fu/lib/curb-fu.rb at master · gdi/curb-fu · GitHub it defines
a stub method already. So you’re hitting that one, which expects two
arguments. stub! goes to RSpec’s mocking framework.

Pat

3

Pat M. wrote:

I’ve never heard of CurbFu, but according to
curb-fu/lib/curb-fu.rb at master · gdi/curb-fu · GitHub 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.

4

On Mar 19, 2010, at 1:27 PM, Nick H. wrote:

Pat M. wrote:

I’ve never heard of CurbFu, but according to
curb-fu/lib/curb-fu.rb at master · gdi/curb-fu · GitHub 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 :slight_smile:

Cheers,
David

5

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

6

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-
[email protected]… So I don’t quite understand why my post was
thrown under this topic…

Oh well, sorry about that and I will repost.

-patrick

7

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.

8

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-
[email protected]… So I don’t quite understand why my post was
thrown under this topic…

Oh well, sorry about that and I will repost.

-patrick

No 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

9

On Fri, Mar 19, 2010 at 1:39 PM, David C. [email protected]
wrote:

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.