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? Thanks for your input, e. -- ericw at xmtp.net "If the answer isn''t violence, neither is your silence!" -- Pop Will Eat Itself, "Ich Bin Ein Auslander"
David Chelimsky
2008-Feb-19 11:42 UTC
[rspec-users] render_to_string in a controller test?
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, 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. FWIW, David> > Thanks for your input, > > e. > -- > 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 > http://rubyforge.org/mailman/listinfo/rspec-users >
On Feb 19, 2008, at 3:42 AM, David Chelimsky wrote:> 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, > 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. WDYT? James Deville http://devillecompanies.org james.deville at gmail.com rspec r3172 rspec_on_rails r3172 rails r8331> > > FWIW, > David > >> >> Thanks for your input, >> >> e. >> -- >> 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 >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
David Chelimsky
2008-Feb-19 18:34 UTC
[rspec-users] render_to_string in a controller test?
On Feb 19, 2008 1:18 PM, James Deville <james.deville at gmail.com> wrote:> > > On Feb 19, 2008, at 3:42 AM, David Chelimsky wrote: > > > 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, > > 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.There already is. You can already integrate_views in a single example group. describe FooController, " ... exception case ..." do integrate_views ... end> > WDYT? > > James Deville > http://devillecompanies.org > james.deville at gmail.com > rspec r3172 > rspec_on_rails r3172 > rails r8331 > > > > > > > > FWIW, > > David > > > >> > >> Thanks for your input, > >> > >> e. > >> -- > >> 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 > >> http://rubyforge.org/mailman/listinfo/rspec-users > >> > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >