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?
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,
should it?
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
integrate_views.
I can work around the issue by using integrate_views, and I guess
instead of a (theoretical) browser should not make a difference,
should it?
I am of two minds on this. On one, I can see testing that the
controller assigns a template to a variable, and then test that the
view is as expected in a view spec. On the other hand, if I am doing a
render to string, then from a testing perspective, I’m assigning a
variable. Whether that variable goes to the browser or a model
shouldn’t matter, we should enable testing of it as a variable.
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
integrate_views.
Perhaps there should be a way to allow render_to_string to render a
without making all views render.
returns the path of the view, rather than the rendered output. This
keeps failures in views isolated to the view specs (why should a
render to string, then from a testing perspective, I’m assigning a
variable. Whether that variable goes to the browser or a model
shouldn’t matter, we should enable testing of it as a variable.
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
integrate_views.
Perhaps there should be a way to allow render_to_string to render a
without making all views render.
There already is. You can already integrate_views in a single example
group.
describe FooController, " … exception case …" do
integrate_views
…
end
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.