On Sun, May 4, 2008 at 10:16 AM, steven shingler [email protected]
partial to be rendered to the screen as part of my default layout, and
I was hoping to be able to verify that the partial loaded.
What would fit my brain better, would be:
Except that responses don’t render anything, controllers do which
result in the body of the response.
Also even if this were
I can’t see how this would work, since it seems to involve backwards
time travel. In a controller spec you use
controller.expect_render(:partial => …)
BEFORE doing a get/post etc. It works like x.should_receive(:foo)
it’s something which needs to be set up before something happens.
…but that isn’t available
I hope that is clearer - I am quite new to the world of rspec.
If you can shed any more light that would be really great.
Rails integration testing happens in the context of a simulated
browser. It’s awkward, if indeed it’s possible at all, to instrument
the mechanisms of controllers and templates here. This is normally
done in controller and/or view specs.
At the story/integration level, I think you really want to be looking
at the result of the http requests, which means you should be setting
expectations about what’s in the response rather than how the response
is going to be constructed.
So instead of trying to determine if the tasks_list partial is being
rendered, why not do something like having the partial generate
evidence that it was invoked in the output, for example it might
generate a div or ol or whatever which contains the tasks list which
has a particular dom id, and then use response.should have_tag to
verify that the task list is in the response?
My blog on Ruby