rspec users - Aug 2007 - expect_render, why does there need to be a warning

There is a warning on the web site about expect_render and stub_render:

"WARNING: expect_render and stub_render, while very useful, act
differently from standard Message Expectations (a.k.a. mock
expectations), which would never pass calls through to the real
object. This can be very confusing when there are failures if you''re
not aware of this fact, because some calls will be passed through
while others will not. This is especially confusing when you use
stub_render because, as with all Method Stubs, you will get very
little feedback about what is going on."

My questions:

Is this a sign that expect_render is doing to much?
Is there a benefit from having expect_render and stub_render sometimes
pass the render call to the underlying template object?
Why not force all partials to be tested individually?

Testing partials individually seems like a cleaner, more consistent
and less confusing route to go, especially when you consider the
nesting of paritals which render other partials.

Zach

On 8/14/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> There is a warning on the web site about expect_render and stub_render:
>
> "WARNING: expect_render and stub_render, while very useful, act
> differently from standard Message Expectations (a.k.a. mock
> expectations), which would never pass calls through to the real
> object. This can be very confusing when there are failures if
you''re
> not aware of this fact, because some calls will be passed through
> while others will not. This is especially confusing when you use
> stub_render because, as with all Method Stubs, you will get very
> little feedback about what is going on."
>
> My questions:
>
> Is this a sign that expect_render is doing to much?
> Is there a benefit from having expect_render and stub_render sometimes
> pass the render call to the underlying template object?
> Why not force all partials to be tested individually?
>
> Testing partials individually seems like a cleaner, more consistent
> and less confusing route to go, especially when you consider the
> nesting of paritals which render other partials.
That''s the whole reason for the existence of expect_render. If
you''re
spec''ing ''_outer_partial'' and you want to specify
that it renders
''_inner_partial'', but you don''t want to actually
render
''_inner_partial'', there is no way to do that with traditional
mocking
frameworks because they are not designed to pay attention to one call
to a method:

  render(:partial => ''_inner_partial'')

while letting another call to the same method:

  render(:partial => ''_outer_partial'')

through to the object. Agreed that expect_partial is doing to much,
but what alternatives do we have?

Cheers,
David

On 8/14/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > Is this a sign that expect_render is doing to much?
> Agreed that expect_partial is doing to much,
Oy vey - we BOTH used the wrong "to". Shame on both of us :)

On 8/14/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > There is a warning on the web site about expect_render and
stub_render:
> >
> > "WARNING: expect_render and stub_render, while very useful, act
> > differently from standard Message Expectations (a.k.a. mock
> > expectations), which would never pass calls through to the real
> > object. This can be very confusing when there are failures if
you''re
> > not aware of this fact, because some calls will be passed through
> > while others will not. This is especially confusing when you use
> > stub_render because, as with all Method Stubs, you will get very
> > little feedback about what is going on."
> >
> > My questions:
> >
> > Is this a sign that expect_render is doing to much?
> > Is there a benefit from having expect_render and stub_render sometimes
> > pass the render call to the underlying template object?
> > Why not force all partials to be tested individually?
> >
> > Testing partials individually seems like a cleaner, more consistent
> > and less confusing route to go, especially when you consider the
> > nesting of paritals which render other partials.
>
> That''s the whole reason for the existence of expect_render. If
you''re
> spec''ing ''_outer_partial'' and you want to
specify that it renders
> ''_inner_partial'', but you don''t want to actually
render
> ''_inner_partial'', there is no way to do that with
traditional mocking
> frameworks because they are not designed to pay attention to one call
> to a method:
>
>   render(:partial => ''_inner_partial'')
>
> while letting another call to the same method:
>
>   render(:partial => ''_outer_partial'')
>
> through to the object. Agreed that expect_partial is doing to much,
> but what alternatives do we have?
When testing views the first call to render is going to be the one
that should be passed to the underlying template, since this is from
the test.

Every subsequent call to render will be done from within the template,
so RSpec can look for a matching expectation. It seems that
expect_render is in charge of setting those up.

If this is done then a simple convention will be enforced, every
inline "render :partial" call will have to be expected in a view spec,
and every view template (or partial) will have to have it''s own view
test.

This gets rid of issues of nesting, confusion and poorly written specs
where someone is asserting contents of a partial rendered multiple
levels deep in the render chain.

Granted you end up with more view tests, but they are cleaner, shorter
and easier to read. More importantly they are easier to maintain and
update because they will be easy to find an existing spec for to start
test driving changes, rather then having to find the view which
renders your partial and the spec that renders that view (and heaven
forbid your partial is used  in several views, and each view tests the
contents of that partial).

Zach

On 8/14/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> On 8/14/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > > There is a warning on the web site about expect_render and
stub_render:
> > >
> > > "WARNING: expect_render and stub_render, while very useful,
act
> > > differently from standard Message Expectations (a.k.a. mock
> > > expectations), which would never pass calls through to the real
> > > object. This can be very confusing when there are failures if
you''re
> > > not aware of this fact, because some calls will be passed through
> > > while others will not. This is especially confusing when you use
> > > stub_render because, as with all Method Stubs, you will get very
> > > little feedback about what is going on."
> > >
> > > My questions:
> > >
> > > Is this a sign that expect_render is doing to much?
> > > Is there a benefit from having expect_render and stub_render
sometimes
> > > pass the render call to the underlying template object?
> > > Why not force all partials to be tested individually?
> > >
> > > Testing partials individually seems like a cleaner, more
consistent
> > > and less confusing route to go, especially when you consider the
> > > nesting of paritals which render other partials.
> >
> > That''s the whole reason for the existence of expect_render.
If you''re
> > spec''ing ''_outer_partial'' and you want to
specify that it renders
> > ''_inner_partial'', but you don''t want to
actually render
> > ''_inner_partial'', there is no way to do that with
traditional mocking
> > frameworks because they are not designed to pay attention to one call
> > to a method:
> >
> >   render(:partial => ''_inner_partial'')
> >
> > while letting another call to the same method:
> >
> >   render(:partial => ''_outer_partial'')
> >
> > through to the object. Agreed that expect_partial is doing to much,
> > but what alternatives do we have?
>
> When testing views the first call to render is going to be the one
> that should be passed to the underlying template, since this is from
> the test.
>
> Every subsequent call to render will be done from within the template,
> so RSpec can look for a matching expectation. It seems that
> expect_render is in charge of setting those up.
>
> If this is done then a simple convention will be enforced, every
> inline "render :partial" call will have to be expected in a view
spec,
> and every view template (or partial) will have to have it''s own
view
> test.
>
> This gets rid of issues of nesting, confusion and poorly written specs
> where someone is asserting contents of a partial rendered multiple
> levels deep in the render chain.
>
> Granted you end up with more view tests, but they are cleaner, shorter
> and easier to read. More importantly they are easier to maintain and
> update because they will be easy to find an existing spec for to start
> test driving changes, rather then having to find the view which
> renders your partial and the spec that renders that view (and heaven
> forbid your partial is used  in several views, and each view tests the
> contents of that partial).
I think you are describing a good convention, but I don''t think rspec
should force it on everybody. The goal here is to provide tools that
ALLOW you to do things in certain ways but not force you to.

For example, rspec_on_rails supports isolated views, but you can do
rails-style functional tests (using controller specs with integrated
views) if you want.

An issue I''ve run into is with a controller using the active_scaffold  
plugin, which injects a method that modifies the search path for  
partial files. When I try to run a spec on a a_s partial it reports  
the file cannot be found.

I think this is the a_s code that does it but I''m not sure where to  
go from there to get rspec to handle it. Any suggestions would be  
appreciated.

file: plugins/active_scaffold/lib/extensions/action_view.rb

module ActionView #:nodoc:
   class Base
	...

     def render_partial_with_active_scaffold(partial_path,  
local_assigns = nil, deprecated_local_assigns = nil) #:nodoc:
       if self.controller.class.respond_to?(:uses_active_scaffold?)  
and self.controller.class.uses_active_scaffold?
         partial_path = rewrite_partial_path_for_active_scaffold 
(partial_path)
       end
       render_partial_without_active_scaffold(partial_path,  
local_assigns, deprecated_local_assigns)
     end
      
alias_method :render_partial_without_active_scaffold, :render_partial
     alias_method :render_partial, :render_partial_with_active_scaffold

     private

     def rewrite_partial_path_for_active_scaffold(partial_path)
       path, partial_name = partial_pieces(partial_path)

       # test for the actual file
       return partial_path if file_exists? File.join(path, "_# 
{partial_name}")

       # check the ActiveScaffold-specific directories
       ActiveScaffold::Config::Core.template_search_path.each do | 
template_path|
         return File.join(template_path, partial_name) if  
file_exists? File.join(template_path, "_#{partial_name}")
       end
       return partial_path
     end
   end
end

On 8/14/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > On 8/14/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > > > There is a warning on the web site about expect_render and
stub_render:
> > > >
> > > > "WARNING: expect_render and stub_render, while very
useful, act
> > > > differently from standard Message Expectations (a.k.a. mock
> > > > expectations), which would never pass calls through to the
real
> > > > object. This can be very confusing when there are failures
if you''re
> > > > not aware of this fact, because some calls will be passed
through
> > > > while others will not. This is especially confusing when you
use
> > > > stub_render because, as with all Method Stubs, you will get
very
> > > > little feedback about what is going on."
> > > >
> > > > My questions:
> > > >
> > > > Is this a sign that expect_render is doing to much?
> > > > Is there a benefit from having expect_render and stub_render
sometimes
> > > > pass the render call to the underlying template object?
> > > > Why not force all partials to be tested individually?
> > > >
> > > > Testing partials individually seems like a cleaner, more
consistent
> > > > and less confusing route to go, especially when you consider
the
> > > > nesting of paritals which render other partials.
> > >
> > > That''s the whole reason for the existence of
expect_render. If you''re
> > > spec''ing ''_outer_partial'' and you want
to specify that it renders
> > > ''_inner_partial'', but you don''t want
to actually render
> > > ''_inner_partial'', there is no way to do that
with traditional mocking
> > > frameworks because they are not designed to pay attention to one
call
> > > to a method:
> > >
> > >   render(:partial => ''_inner_partial'')
> > >
> > > while letting another call to the same method:
> > >
> > >   render(:partial => ''_outer_partial'')
> > >
> > > through to the object. Agreed that expect_partial is doing to
much,
> > > but what alternatives do we have?
> >
> > When testing views the first call to render is going to be the one
> > that should be passed to the underlying template, since this is from
> > the test.
> >
> > Every subsequent call to render will be done from within the template,
> > so RSpec can look for a matching expectation. It seems that
> > expect_render is in charge of setting those up.
> >
> > If this is done then a simple convention will be enforced, every
> > inline "render :partial" call will have to be expected in a
view spec,
> > and every view template (or partial) will have to have it''s
own view
> > test.
> >
> > This gets rid of issues of nesting, confusion and poorly written specs
> > where someone is asserting contents of a partial rendered multiple
> > levels deep in the render chain.
> >
> > Granted you end up with more view tests, but they are cleaner, shorter
> > and easier to read. More importantly they are easier to maintain and
> > update because they will be easy to find an existing spec for to start
> > test driving changes, rather then having to find the view which
> > renders your partial and the spec that renders that view (and heaven
> > forbid your partial is used  in several views, and each view tests the
> > contents of that partial).
>
> I think you are describing a good convention, but I don''t think
rspec
> should force it on everybody. The goal here is to provide tools that
> ALLOW you to do things in certain ways but not force you to.
>
> For example, rspec_on_rails supports isolated views, but you can do
> rails-style functional tests (using controller specs with integrated
> views) if you want.
How about a "integrate_inline_renders" similar to
"integrate_views"?

Zach

On 8/15/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> On 8/14/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > > On 8/14/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> > > > On 8/14/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> > > > > There is a warning on the web site about expect_render
and stub_render:
> > > > >
> > > > > "WARNING: expect_render and stub_render, while
very useful, act
> > > > > differently from standard Message Expectations (a.k.a.
mock
> > > > > expectations), which would never pass calls through to
the real
> > > > > object. This can be very confusing when there are
failures if you''re
> > > > > not aware of this fact, because some calls will be
passed through
> > > > > while others will not. This is especially confusing
when you use
> > > > > stub_render because, as with all Method Stubs, you will
get very
> > > > > little feedback about what is going on."
> > > > >
> > > > > My questions:
> > > > >
> > > > > Is this a sign that expect_render is doing to much?
> > > > > Is there a benefit from having expect_render and
stub_render sometimes
> > > > > pass the render call to the underlying template object?
> > > > > Why not force all partials to be tested individually?
> > > > >
> > > > > Testing partials individually seems like a cleaner,
more consistent
> > > > > and less confusing route to go, especially when you
consider the
> > > > > nesting of paritals which render other partials.
> > > >
> > > > That''s the whole reason for the existence of
expect_render. If you''re
> > > > spec''ing ''_outer_partial'' and you
want to specify that it renders
> > > > ''_inner_partial'', but you don''t
want to actually render
> > > > ''_inner_partial'', there is no way to do
that with traditional mocking
> > > > frameworks because they are not designed to pay attention to
one call
> > > > to a method:
> > > >
> > > >   render(:partial => ''_inner_partial'')
> > > >
> > > > while letting another call to the same method:
> > > >
> > > >   render(:partial => ''_outer_partial'')
> > > >
> > > > through to the object. Agreed that expect_partial is doing
to much,
> > > > but what alternatives do we have?
> > >
> > > When testing views the first call to render is going to be the
one
> > > that should be passed to the underlying template, since this is
from
> > > the test.
> > >
> > > Every subsequent call to render will be done from within the
template,
> > > so RSpec can look for a matching expectation. It seems that
> > > expect_render is in charge of setting those up.
> > >
> > > If this is done then a simple convention will be enforced, every
> > > inline "render :partial" call will have to be expected
in a view spec,
> > > and every view template (or partial) will have to have
it''s own view
> > > test.
> > >
> > > This gets rid of issues of nesting, confusion and poorly written
specs
> > > where someone is asserting contents of a partial rendered
multiple
> > > levels deep in the render chain.
> > >
> > > Granted you end up with more view tests, but they are cleaner,
shorter
> > > and easier to read. More importantly they are easier to maintain
and
> > > update because they will be easy to find an existing spec for to
start
> > > test driving changes, rather then having to find the view which
> > > renders your partial and the spec that renders that view (and
heaven
> > > forbid your partial is used  in several views, and each view
tests the
> > > contents of that partial).
> >
> > I think you are describing a good convention, but I don''t
think rspec
> > should force it on everybody. The goal here is to provide tools that
> > ALLOW you to do things in certain ways but not force you to.
> >
> > For example, rspec_on_rails supports isolated views, but you can do
> > rails-style functional tests (using controller specs with integrated
> > views) if you want.
>
> How about a "integrate_inline_renders" similar to
"integrate_views"?
Just don''t use expect_render and it''ll do that. Magic!
>
> Zach
>

On 8/15/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 8/15/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > On 8/14/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 8/14/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > > > On 8/14/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> > > > > On 8/14/07, Zach Dennis <zach.dennis at
gmail.com> wrote:
> > > > > > There is a warning on the web site about
expect_render and stub_render:
> > > > > >
> > > > > > "WARNING: expect_render and stub_render,
while very useful, act
> > > > > > differently from standard Message Expectations
(a.k.a. mock
> > > > > > expectations), which would never pass calls
through to the real
> > > > > > object. This can be very confusing when there are
failures if you''re
> > > > > > not aware of this fact, because some calls will be
passed through
> > > > > > while others will not. This is especially
confusing when you use
> > > > > > stub_render because, as with all Method Stubs, you
will get very
> > > > > > little feedback about what is going on."
> > > > > >
> > > > > > My questions:
> > > > > >
> > > > > > Is this a sign that expect_render is doing to
much?
> > > > > > Is there a benefit from having expect_render and
stub_render sometimes
> > > > > > pass the render call to the underlying template
object?
> > > > > > Why not force all partials to be tested
individually?
> > > > > >
> > > > > > Testing partials individually seems like a
cleaner, more consistent
> > > > > > and less confusing route to go, especially when
you consider the
> > > > > > nesting of paritals which render other partials.
> > > > >
> > > > > That''s the whole reason for the existence of
expect_render. If you''re
> > > > > spec''ing ''_outer_partial''
and you want to specify that it renders
> > > > > ''_inner_partial'', but you
don''t want to actually render
> > > > > ''_inner_partial'', there is no way to
do that with traditional mocking
> > > > > frameworks because they are not designed to pay
attention to one call
> > > > > to a method:
> > > > >
> > > > >   render(:partial =>
''_inner_partial'')
> > > > >
> > > > > while letting another call to the same method:
> > > > >
> > > > >   render(:partial =>
''_outer_partial'')
> > > > >
> > > > > through to the object. Agreed that expect_partial is
doing to much,
> > > > > but what alternatives do we have?
> > > >
> > > > When testing views the first call to render is going to be
the one
> > > > that should be passed to the underlying template, since this
is from
> > > > the test.
> > > >
> > > > Every subsequent call to render will be done from within the
template,
> > > > so RSpec can look for a matching expectation. It seems that
> > > > expect_render is in charge of setting those up.
> > > >
> > > > If this is done then a simple convention will be enforced,
every
> > > > inline "render :partial" call will have to be
expected in a view spec,
> > > > and every view template (or partial) will have to have
it''s own view
> > > > test.
> > > >
> > > > This gets rid of issues of nesting, confusion and poorly
written specs
> > > > where someone is asserting contents of a partial rendered
multiple
> > > > levels deep in the render chain.
> > > >
> > > > Granted you end up with more view tests, but they are
cleaner, shorter
> > > > and easier to read. More importantly they are easier to
maintain and
> > > > update because they will be easy to find an existing spec
for to start
> > > > test driving changes, rather then having to find the view
which
> > > > renders your partial and the spec that renders that view
(and heaven
> > > > forbid your partial is used  in several views, and each view
tests the
> > > > contents of that partial).
> > >
> > > I think you are describing a good convention, but I
don''t think rspec
> > > should force it on everybody. The goal here is to provide tools
that
> > > ALLOW you to do things in certain ways but not force you to.
> > >
> > > For example, rspec_on_rails supports isolated views, but you can
do
> > > rails-style functional tests (using controller specs with
integrated
> > > views) if you want.
> >
> > How about a "integrate_inline_renders" similar to
"integrate_views"?
>
> Just don''t use expect_render and it''ll do that. Magic!
>
I''m on the opposite view point. I don''t want to pass through
renders,
I want to force all inline renders to be enforced.

If i have a view that calls "render :partial =>
''foo''" and I don''t use
expect_render I want it to yell at me saying an unexpected call was
made on the template.

Zach

On 8/15/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> On 8/15/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/15/07, Zach Dennis <zach.dennis at gmail.com> wrote:
> > > On 8/14/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> > > > On 8/14/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> > > > > On 8/14/07, David Chelimsky <dchelimsky at
gmail.com> wrote:
> > > > > > On 8/14/07, Zach Dennis <zach.dennis at
gmail.com> wrote:
> > > > > > > There is a warning on the web site about
expect_render and stub_render:
> > > > > > >
> > > > > > > "WARNING: expect_render and stub_render,
while very useful, act
> > > > > > > differently from standard Message
Expectations (a.k.a. mock
> > > > > > > expectations), which would never pass calls
through to the real
> > > > > > > object. This can be very confusing when there
are failures if you''re
> > > > > > > not aware of this fact, because some calls
will be passed through
> > > > > > > while others will not. This is especially
confusing when you use
> > > > > > > stub_render because, as with all Method
Stubs, you will get very
> > > > > > > little feedback about what is going on."
> > > > > > >
> > > > > > > My questions:
> > > > > > >
> > > > > > > Is this a sign that expect_render is doing to
much?
> > > > > > > Is there a benefit from having expect_render
and stub_render sometimes
> > > > > > > pass the render call to the underlying
template object?
> > > > > > > Why not force all partials to be tested
individually?
> > > > > > >
> > > > > > > Testing partials individually seems like a
cleaner, more consistent
> > > > > > > and less confusing route to go, especially
when you consider the
> > > > > > > nesting of paritals which render other
partials.
> > > > > >
> > > > > > That''s the whole reason for the existence
of expect_render. If you''re
> > > > > > spec''ing
''_outer_partial'' and you want to specify that it renders
> > > > > > ''_inner_partial'', but you
don''t want to actually render
> > > > > > ''_inner_partial'', there is no
way to do that with traditional mocking
> > > > > > frameworks because they are not designed to pay
attention to one call
> > > > > > to a method:
> > > > > >
> > > > > >   render(:partial =>
''_inner_partial'')
> > > > > >
> > > > > > while letting another call to the same method:
> > > > > >
> > > > > >   render(:partial =>
''_outer_partial'')
> > > > > >
> > > > > > through to the object. Agreed that expect_partial
is doing to much,
> > > > > > but what alternatives do we have?
> > > > >
> > > > > When testing views the first call to render is going to
be the one
> > > > > that should be passed to the underlying template, since
this is from
> > > > > the test.
> > > > >
> > > > > Every subsequent call to render will be done from
within the template,
> > > > > so RSpec can look for a matching expectation. It seems
that
> > > > > expect_render is in charge of setting those up.
> > > > >
> > > > > If this is done then a simple convention will be
enforced, every
> > > > > inline "render :partial" call will have to be
expected in a view spec,
> > > > > and every view template (or partial) will have to have
it''s own view
> > > > > test.
> > > > >
> > > > > This gets rid of issues of nesting, confusion and
poorly written specs
> > > > > where someone is asserting contents of a partial
rendered multiple
> > > > > levels deep in the render chain.
> > > > >
> > > > > Granted you end up with more view tests, but they are
cleaner, shorter
> > > > > and easier to read. More importantly they are easier to
maintain and
> > > > > update because they will be easy to find an existing
spec for to start
> > > > > test driving changes, rather then having to find the
view which
> > > > > renders your partial and the spec that renders that
view (and heaven
> > > > > forbid your partial is used  in several views, and each
view tests the
> > > > > contents of that partial).
> > > >
> > > > I think you are describing a good convention, but I
don''t think rspec
> > > > should force it on everybody. The goal here is to provide
tools that
> > > > ALLOW you to do things in certain ways but not force you to.
> > > >
> > > > For example, rspec_on_rails supports isolated views, but you
can do
> > > > rails-style functional tests (using controller specs with
integrated
> > > > views) if you want.
> > >
> > > How about a "integrate_inline_renders" similar to
"integrate_views"?
> >
> > Just don''t use expect_render and it''ll do that.
Magic!
> >
>
> I''m on the opposite view point. I don''t want to pass
through renders,
> I want to force all inline renders to be enforced.
>
> If i have a view that calls "render :partial =>
''foo''" and I don''t use
> expect_render I want it to yell at me saying an unexpected call was
> made on the template.
There''s nothing else in rspec_on_rails that yells at you because you
don''t like to organize your specs the way rspec thinks they should be
organized, so I definitely wouldn''t support this being default
behaviour.

I could see, maybe, the possibility of having a command like
disallow_unexpected_renders or something like that, but I honestly
don''t see that much value in it in return for the additional
complexity (didn''t you start by saying this was too complex already?).

I understand that you DO see value in this, and I''d encourage you to
write a plugin that makes this work the way you want and feel free to
publish it.

Cheers,
David

> >
> > If i have a view that calls "render :partial =>
''foo''" and I don''t use
> > expect_render I want it to yell at me saying an unexpected call was
> > made on the template.
>
> There''s nothing else in rspec_on_rails that yells at you because
you
> don''t like to organize your specs the way rspec thinks they should
be
> organized, so I definitely wouldn''t support this being default
> behaviour.
It was worth a shot.
>
> I could see, maybe, the possibility of having a command like
> disallow_unexpected_renders or something like that, but I honestly
> don''t see that much value in it in return for the additional
> complexity (didn''t you start by saying this was too complex
already?).
To summarize for anyone else reading this or possibly picking it up in
an archive down the road.

I was wanting to have a one to one, view to spec. If I had a template
called "show.html.erb" I want
a "show.html.erb_spec.rb". If "show" had an inline call to
render the
partial "foo" I want to have
a "_foo.html.erb_spec.rb" to test that partial. The one way I see how
this can work is to have
rspec_on_rails treat all inline render calls as expectations. This
would result in a
"unexpected call to render :partial => ''foo''"
when I ran my "show"
spec if I didn''t have an "expect_render :partial =>
''foo''"
line.

I do not want to be able to test the contents of the partial "foo"
inside of my "show" spec. The reasons
I do not want:
 - possibly multiple view specs testing the same partial
 - possibly multiple places for each partial to be tested, I''d rather
make it easy to know where to go when updating a view and its spec
 - to add time for a developer having to search for what view a
partial is being rendered in and then checking to see if that view''s
spec is testing the contents of the partial

I do want:
 - consistency, expect_render is an expectation, let it be consistent
with how expectations work, I should not get a passing test by
potentially rendering the wrong thing
 - ease of maintainability and readability (which I see a single
location is easier to maintain and read then potentially multiple
spots)

I see the convention of one view to one spec adding more value then it
takes away. I may be a little to hardcore though, I also think that
"integrate_views" in controller specs should just go away.

>
> I understand that you DO see value in this, and I''d encourage you
to
> write a plugin that makes this work the way you want and feel free to
> publish it.
>
I think I''ll have to give that a try. Thanks David,

Zach

On 8/16/07, Zach Dennis <zach.dennis at gmail.com>
wrote:
> > >
> > > If i have a view that calls "render :partial =>
''foo''" and I don''t use
> > > expect_render I want it to yell at me saying an unexpected call
was
> > > made on the template.
> >
> > There''s nothing else in rspec_on_rails that yells at you
because you
> > don''t like to organize your specs the way rspec thinks they
should be
> > organized, so I definitely wouldn''t support this being
default
> > behaviour.
>
> It was worth a shot.
>
> >
> > I could see, maybe, the possibility of having a command like
> > disallow_unexpected_renders or something like that, but I honestly
> > don''t see that much value in it in return for the additional
> > complexity (didn''t you start by saying this was too complex
already?).
>
> To summarize for anyone else reading this or possibly picking it up in
> an archive down the road.
>
> I was wanting to have a one to one, view to spec.
You can have that. But you don''t have to. It''s your choice.
> If I had a template
> called "show.html.erb" I want
> a "show.html.erb_spec.rb". If "show" had an inline call
to render the
> partial "foo" I want to have
> a "_foo.html.erb_spec.rb" to test that partial.
There is nothing stopping you from doing this.
> The one way I see how
> this can work is to have
> rspec_on_rails treat all inline render calls as expectations.
Again, there''s nothing stopping you from doing this. There''s
nothing
forcing you to either. That''s an important point.
>This
> would result in a
> "unexpected call to render :partial =>
''foo''" when I ran my "show"
> spec if I didn''t have an "expect_render :partial =>
''foo''"
> line.
>
> I do not want to be able to test the contents of the partial
"foo"
> inside of my "show" spec.
If you''re actually driving your design with the specs, which is what
rspec is designed to encourage, the way you do it is this:

Spec-drive a view. At the end of several red/green/refactor cycles
you''ll likely have one spec and one view.

Spec-drive another view.

Recognize that both views display some of the same stuff.

Extract the common stuff into a partial.

This last step is refactoring: changing the design without changing
the behaviour. Refactoring, ideally, should not require changing any
specs. The way things are currently, after you extract the partial,
you can run the specs and they pass. With rspec forcing things to work
the way you seem to want it to, you couldn''t change the design without
causing failing specs.

After you''ve refactored the design, extracting the partial, perhaps
you want to restructure the specs so that there is only one spec for
the partial. At this point, you create a new spec for the partial,
moving the examples from one of the two view specs to the partial
spec, and then remove the duplicate examples from the other.

BDD is a process, not a result. The tools should support the process.
What you''re asking for would stand in the way of this process.
> The reasons
> I do not want:
>  - possibly multiple view specs testing the same partial
>  - possibly multiple places for each partial to be tested, I''d
rather
> make it easy to know where to go when updating a view and its spec
>  - to add time for a developer having to search for what view a
> partial is being rendered in and then checking to see if that
view''s
> spec is testing the contents of the partial
>
> I do want:
>  - consistency, expect_render is an expectation, let it be consistent
> with how expectations work, I should not get a passing test by
> potentially rendering the wrong thing
How can this happen if you''re writing the specs first?
>  - ease of maintainability and readability (which I see a single
> location is easier to maintain and read then potentially multiple
> spots)
Again, there''s nothing stopping you from getting to this.
> I see the convention of one view to one spec adding more value then it
> takes away.
There''s a difference between convention and handcuffs. What you are
proposing is handcuffs. There is absolutely nothing stopping you from
following this convention.
> I may be a little to hardcore though, I also think that
> "integrate_views" in controller specs should just go away.
Again, while RSpec is opinionated in some ways, it also needs to be
flexible. Obviously there are boundaries to this, but you and I seem
to have these boundaries in different places.

The fact that the default is to not integrate views guides you in the
direction of strict isolation. But with strict isolation comes a cost,
which is that you can get all your component specs working and the app
doesn''t run because you never had any integration tests. For some,
using integrate_views takes the place of having integration tests.
Although this is not the approach that I like to take, it is a
perfectly reasonable approach and I think it would be wrong for rspec
to disallow this.
> > I understand that you DO see value in this, and I''d encourage
you to
> > write a plugin that makes this work the way you want and feel free to
> > publish it.
> >
>
> I think I''ll have to give that a try. Thanks David,
>
> Zach
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

> BDD is a process, not a result. The tools should support the process.
> What you''re asking for would stand in the way of this process.
If there is a "disallow_unexpected_renders" that does not stand in the
way of the process. It gives people a choice, much like
integrate_views gives people a choice.

Although I see people using integrate_views are disabling themselves,
because they are probably writing horrible specs. Using controller
specs to double as view specs to make up for not having integration
specs is a big problem in itself.

And I see disallow_unexpected_renders enabling themselves to not test
the same partials in more then one spot.

I get your point though, it''s not getting in. Thats ok,

Zach