Forum: RSpec Mocking / stubbing errors for ActiveRecord

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Martin N. (Guest)
on 2009-02-19 23:04
(Received via mailing list)
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
Matt W. (Guest)
on 2009-02-19 23:46
(Received via mailing list)
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
Bart Z. (Guest)
on 2009-02-20 00:06
(Received via mailing list)
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
Jim G. (Guest)
on 2009-02-20 00:06
(Received via mailing list)
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
David C. (Guest)
on 2009-02-20 00:08
(Received via mailing list)
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
Zach D. (Guest)
on 2009-02-20 00:18
(Received via mailing list)
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
Zach D. (Guest)
on 2009-02-20 00:33
(Received via mailing list)
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
Zach D. (Guest)
on 2009-02-20 00:59
(Received via mailing list)
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
Matt W. (Guest)
on 2009-02-20 16:53
(Received via mailing list)
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
Zach D. (Guest)
on 2009-02-20 17:25
(Received via mailing list)
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
Pat M. (Guest)
on 2009-02-20 20:27
(Received via mailing list)
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
Zach D. (Guest)
on 2009-02-20 21:57
(Received via mailing list)
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
Martin N. (Guest)
on 2009-02-21 14:59
(Received via mailing list)
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-rspe... which is a
nice introduction to it.

Thanks again,
Martin
This topic is locked and can not be replied to.