From the perspective of the view, it has to 'know' a priori how the controller is providing data, either instance variables or expose'd methods etc. I've been changing some controllers over to using respond_to/respond_with ala episode 224 (http://railscasts.com/episodes/224-controllers-in-rails-3). The only stumbling block for me is that the view template still needs to know how the controller is providing data, even though the controller specified 'respond_with widgets' (or 'respond_with @widgets'). Non-templated requests, e.g. /widgets/index.xml, are picking up the correct data, but I don't see a clean way of determining in the view template (say index.html.haml) what the controller said to respond_with. The real pain point here is when I'm rendering partials. At the moment I'm having to call the partial with a :locals hash.
Of course, I could be way out in left field here. If I am, please leave some breadcrumbs so I can get back home.
To make sure I understand, what you are suggesting is that in the functional test to only check the result in general terms, e.g. 'assert_response :success' or 'assert_redirected_to some_path' etc depending on the expected result, and in an integration test look through the response.body for detailed content?
As long as we're talking theory & coupling...
From the perspective of the view, it has to 'know' a priori how the controller is providing data, either instance variables or expose'd methods etc. I've been changing some controllers over to using respond_to/respond_with ala episode 224 (http://railscasts.com/episodes/224-controllers-in-rails-3). The only stumbling block for me is that the view template still needs to know how the controller is providing data, even though the controller specified 'respond_with widgets' (or 'respond_with @widgets'). Non-templated requests, e.g. /widgets/index.xml, are picking up the correct data, but I don't see a clean way of determining in the view template (say index.html.haml) what the controller said to respond_with. The real pain point here is when I'm rendering partials. At the moment I'm having to call the partial with a :locals hash.
Of course, I could be way out in left field here. If I am, please leave some breadcrumbs so I can get back home.
@Stephen Caudill, Thank you for the response.
To make sure I understand, what you are suggesting is that in the functional test to only check the result in general terms, e.g. 'assert_response :success' or 'assert_redirected_to some_path' etc depending on the expected result, and in an integration test look through the response.body for detailed content?
To answer my own question, here's one possibility:
assert @controller.users.size > 0
Not sure if I like it. Actually, pretty sure I don't.
The first regression test I ran after changing an existing controller over to using this failed on:
assert_not_nil assigns(:users)
Since instance variables aren't being set, clearly assigns() will always return nil.
examining 'users.size' in the test returns 0.
Visually examining the response.body, I can see that it is correct. Any ideas for a replacement assert?