I like mocks and stubs and I use them liberally in my tests. This practice, however, is not without danger: If my models, views, and controllers are all tested in isolation then how will I know if a model change busts a controller or a view? Here's something I like to drop in at the end of every controller spec:
1
2
3
4
5
6
7
8
9
10
11
12
|
describe JerkStoreController, "with views integrated and real objects" do
integrate_views
it "should render the page without blowing up" do
store = JerkStore.create!(:name => "Costanza's house of bargins")
store.products << Jerk.create!(:name => "Puddy") <<
Jerk.create!(:name => "Newman") <<
Jerk.create!(:name => "Steinbrenner")
post :show, :id => store.id
end
end |
Not a mock or a stub as far as the eye can see and I'm even integrating views. Normally RSpec doesn't render the view in a controller spec, but if you include "integrate_views" it will. So now if I make some changes that bust MVC integration my spec will let me know. I don't try to exercise all the possible paths with these tests -- rather they are a safety net for problems isolated specs won't detect.
Comments
it "renders" do;assigns[:post]=posts(:one); render 'show';end
approach
have you considered cucumber/webrat - by rendering your views and clicking on actual links and filling out forms instead of just posting to your actions this spans a much wider range of problems than a simple "render this view in this action" call