rspec users - Feb 2009 - Mocking / stubbing errors for ActiveRecord

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

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
> Thank you,
> Martin

On Thu, Feb 19, 2009 at 2:54 PM, Martin <html-kurs at gmx.de>
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
>
> Thank you,
> Martin
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

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 Wynne
http://blog.mattwynne.net
http://www.songkick.com

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

On Thu, Feb 19, 2009 at 3:54 PM, Martin <html-kurs at gmx.de>
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
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne <matt at mattwynne.net>
wrote:
>
> 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
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

>
> Does that help?
>
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Thu, Feb 19, 2009 at 4:51 PM, Zach Dennis <zach.dennis at gmail.com>
wrote:
> On Thu, Feb 19, 2009 at 3:54 PM, Martin <html-kurs at gmx.de> 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
>
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.
> Note, that if your model really exists, you can use stub_model instead
> of mock_model.
>
>
>
>
>>
>> Thank you,
>> Martin
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On 19 Feb 2009, at 21:53, Zach Dennis wrote:
> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne <matt at mattwynne.net>  
> wrote:
>>
>> 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
>
> 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
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 Wynne
http://blog.mattwynne.net
http://www.songkick.com

On Fri, Feb 20, 2009 at 9:20 AM, Matt Wynne <matt at mattwynne.net>
wrote:
>
> On 19 Feb 2009, at 21:53, Zach Dennis wrote:
>
>> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne <matt at
mattwynne.net> wrote:
>>>
>>> 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
>>
>> 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
>
> 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 Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Fri, Feb 20, 2009 at 6:20 AM, Matt Wynne <matt at mattwynne.net>
wrote:
>
> On 19 Feb 2009, at 21:53, Zach Dennis wrote:
>
>> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne <matt at
mattwynne.net> wrote:
>>>
>>> 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
>>
>> 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
>
> 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

On Fri, Feb 20, 2009 at 12:59 PM, Pat Maddox <pat.maddox at gmail.com>
wrote:
> On Fri, Feb 20, 2009 at 6:20 AM, Matt Wynne <matt at mattwynne.net>
wrote:
>>
>> On 19 Feb 2009, at 21:53, Zach Dennis wrote:
>>
>>> On Thu, Feb 19, 2009 at 4:24 PM, Matt Wynne <matt at
mattwynne.net> wrote:
>>>>
>>>> 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
>>>
>>> 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
>>
>> 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 Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

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