Mocking / stubbing errors for ActiveRecord


#1

Hi,

I’m trying to test my views using rspec. I want to test my edit- and
new-view also for the case an error occurs (something like “title can’t
be blank” and so on).
Can someone point me please to an example where I can see how to mock my
model and stub all methods needed for the view?

Thank you,
Martin


#2

On 19 feb 2009, at 21:54, Martin wrote:

Hi,

I’m trying to test my views using rspec. I want to test my edit- and
new-view also for the case an error occurs (something like “title
can’t be blank” and so on).
Can someone point me please to an example where I can see how to
mock my model and stub all methods needed for the view?

If you happen to use Cucumber as well, I strongly suggest you check
the error messages there. First of all, it’s easier since you don’t
have to go mad stubbing and mucking about (sorry, had to make that
joke :P), and error messages more or less belong into integration
tests. At least, that’s my opinion.

cheers,
bartz


#3

On 19 Feb 2009, at 20:54, Martin wrote:

Hi,

I’m trying to test my views using rspec. I want to test my edit- and
new-view also for the case an error occurs (something like “title
can’t be blank” and so on).
Can someone point me please to an example where I can see how to
mock my model and stub all methods needed for the view?

I guess this isn’t exactly what you want to hear, but I would counsel
you against mocking your whole model object for a form with lots of
fields - those kind of ‘broad’ mocks can be very brittle to changes in
your domain model.

Can you try using stub_model instead? This creates an instance of your
actual model class, but with a crippled database connection. You can
then create an invalid model object and throw it to the view.
Something like:

assigns[:book] = stub_model(Book, :title => ‘’)

If your model is at all interesting, you might want to keep the
attributes that make a valid Book somewhere:

valid_book = {
:title => “Test Book Title”,
:author => “Test Author”
}
assigns[:book] = stub_model(Book, valid_book.merge(:title => ‘’))

I generally hide these behind a helper method, like

def stub_book(attributes = {})
stub_model Book, {
:title => “Test Book Title”,
:author => “Test Author”
}.merge(attributes)
end

Does that help?

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#4

On Feb 19, 2009, at 3:54 PM, Martin wrote:

Hi,

I’m trying to test my views using rspec. I want to test my edit- and
new-view also for the case an error occurs (something like “title
can’t be blank” and so on).
Can someone point me please to an example where I can see how to
mock my model and stub all methods needed for the view?

Here’s how I addressed it http://pastie.org/394417


#5

On Thu, Feb 19, 2009 at 4:24 PM, Matt W. removed_email_address@domain.invalid wrote:

def stub_book(attributes = {})
stub_model Book, {
:title => “Test Book Title”,
:author => “Test Author”
}.merge(attributes)
end

Why hide them behind a helper? Why not just only specify them in
examples where they are used? ie:

it “should display the book title” do
@book.stub!(:title).and_return “The Scarlet Letter”
render …
response.should include_text(“The Scarlet Letter”)
end

http://rubyforge.org/mailman/listinfo/rspec-users


Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com


#6

On Thu, Feb 19, 2009 at 2:54 PM, Martin removed_email_address@domain.invalid wrote:

Hi,

I’m trying to test my views using rspec. I want to test my edit- and
new-view also for the case an error occurs (something like “title can’t be
blank” and so on).
Can someone point me please to an example where I can see how to mock my
model and stub all methods needed for the view?

Here’s a start:

http://rspec.info/rails/writing/views.html

Also:

rails foo
cd foo
script/generate rspec
script/generate rspec_scaffold thing name:string

Now look at spec/views/things/*.html.erb_spec.rb

HTH,
David


#7

On Thu, Feb 19, 2009 at 4:51 PM, Zach D. removed_email_address@domain.invalid
wrote:

http://gist.github.com/67135

This gist is to show you how-to verify errors are displayed in a view,
not necessarily that you should go stubbing a bunch of superfluous
errors that may exist in the model to ensure they all show up. You
should only need to know that the errors are being displayed and one
dummy error message does that.

rspec-users mailing list


Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com


#8

On Thu, Feb 19, 2009 at 3:54 PM, Martin removed_email_address@domain.invalid wrote:

Hi,

I’m trying to test my views using rspec. I want to test my edit- and
new-view also for the case an error occurs (something like “title can’t be
blank” and so on).
Can someone point me please to an example where I can see how to mock my
model and stub all methods needed for the view?

Here’s two ways to approach writing examples against ensuring errors
show up:

http://gist.github.com/67135

Note, that if your model really exists, you can use stub_model instead
of mock_model.

Thank you,
Martin


rspec-users mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/rspec-users


Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com


#9

On 19 Feb 2009, at 21:53, Zach D. wrote:

blank" and so on).
model.
If your model is at all interesting, you might want to keep the

it “should display the book title” do
@book.stub!(:title).and_return “The Scarlet Letter”
render …
response.should include_text(“The Scarlet Letter”)
end

Why hide them in a helper? because I don’t want the noise of all the
attributes needed to make a valid book in each test.

@book = stub_book :title => “The Scarlet Letter”

This is basically the same pattern people use things like factory_girl
for, just using stub_model.

Matt W.
http://blog.mattwynne.net
http://www.songkick.com


#10

On Fri, Feb 20, 2009 at 9:20 AM, Matt W. removed_email_address@domain.invalid wrote:

new-view also for the case an error occurs (something like "title can’t
Can you try using stub_model instead? This creates an instance of your
:title => “Test Book Title”,
}.merge(attributes)

Why hide them in a helper? because I don’t want the noise of all the
attributes needed to make a valid book in each test.

@book = stub_book :title => “The Scarlet Letter”

This is basically the same pattern people use things like factory_girl for,
just using stub_model.

Ah, I’m with you now. I thought you were eluding to doing the
following (but I realize now that wasn’t what you were getting at):

assigns[:book] = stub_book
render ..
response.should include_text("The Scarlet Letter")


Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com


#11

On Fri, Feb 20, 2009 at 12:59 PM, Pat M. removed_email_address@domain.invalid
wrote:

I’m trying to test my views using rspec. I want to test my edit- and

valid_book = {
:author => “Test Author”
end

Why hide them in a helper? because I don’t want the noise of all the
attributes needed to make a valid book in each test.

Also so that when you change validations, you only have to change one
part of test code instead of every test that uses that model.

Right, it wasn’t what I thought Matt was getting at. I thought he was
specifically referring to hiding things pertinent in a view spec
behind a helper. But that turned out to not be the case,


Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com


#12

Hello alltogether,

thanks for your help. A mixture of stub_model and .errors.stub!() helped
me to solve my problem.

I also stumbled across the right arguments of have_tag. I thought it’s
similar to assert_select as the docs said. But it isn’t. I found
http://rubypond.com/articles/2008/03/31/using-rspec-have_tag/ which is a
nice introduction to it.

Thanks again,
Martin


#13

On Fri, Feb 20, 2009 at 6:20 AM, Matt W. removed_email_address@domain.invalid wrote:

new-view also for the case an error occurs (something like "title can’t
Can you try using stub_model instead? This creates an instance of your
:title => “Test Book Title”,
}.merge(attributes)

Why hide them in a helper? because I don’t want the noise of all the
attributes needed to make a valid book in each test.

Also so that when you change validations, you only have to change one
part of test code instead of every test that uses that model.

Pat