[rspec-users] expect_render, why does there need to be a warning

Zach Dennis zach.dennis at gmail.com
Thu Aug 16 10:11:47 EDT 2007

> >
> > 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'"

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

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,


More information about the rspec-users mailing list