Sprinkle Some Integration Tests into a Mock Heavy Test Suite

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

Michael said…
This can get very complex once your create/view logic is not so simple anymore(not to mention validations...). Therefor i try to stay with the
it "renders" do;assigns[:post]=posts(:one); render 'show';end

approach
alex said…
i think that's a good start but ultimately you might want to start writing full blown integration/acceptance tests.

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

Popular posts from this blog

Point Inside a Polygon in Ruby

SICP Wasn’t Written for You

What's a Good Flog Score?