[rspec-users] render_to_string in a controller test?
dchelimsky at gmail.com
Tue Feb 19 06:42:13 EST 2008
On Feb 18, 2008 8:10 PM, EAW <ericw at xmtp.net> wrote:
> Hi all,
> I know that in general, view and controller tests should be isolated,
> such that controller specs don't test views etc. However, I think
> I've run into a situation that might be an exception.
> My controller uses render_to_string to produce a chunk of HTML that it
> passes to a model to be processed.
> The controller then redirects the user to a different page. The
> results of the render_to_string are not seen by the user.
> Since the controller is calling render_to_string, I've been trying to
> test that it is rendered correctly in my controller spec. Because a
> controller spec normally doesn't render views, render_to_string just
> returns the path of the view, rather than the rendered output. This
> prevents me from testing the output of render_to_string in the
> controller spec.
> I can work around the issue by using integrate_views, and I guess
> that's fine, but shouldn't render_to_string really work in controllers?
The whole point of isolation is to isolate the code in the controller
from the code in the view. The two primary reasons for this are that
it allows you to write controller code before the view exists and it
keeps failures in views isolated to the view specs (why should a
controller spec fail because of a typo in a view?).
The fact that the result of rendering is being passed to a model
instead of a (theoretical) browser should not make a difference,
I can see your argument for wanting to be able to treat this example
differently, and you can, as you pointed out, accomplish that with
> Thanks for your input,
> ericw at xmtp.net
> "If the answer isn't violence, neither is your silence!"
> -- Pop Will Eat Itself, "Ich Bin Ein Auslander"
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users