[rspec-users] expect_render, why does there need to be a warning
zach.dennis at gmail.com
Tue Aug 14 10:01:49 EDT 2007
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
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
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).
More information about the rspec-users