I can imagine you have seen lots of posts about this subject. Well here is another one. For anyone who has used script/generate rspec_scaffold in the past knows that it generates a lot of specs for your controller and views.
Here is a list of issues I have with the auto-generated specs. They are very wordy. Almost 50 lines for the controller update action. Over 60 lines for testing routes. The majority of testing performed is related to testing the framework’s functionality, which in my opinion is not necessary. Another problem I have with it is the fact that as soon as you start nesting resources most of your specs will fail. You will have to adjust them to understand the new nesting setup you have going on. That is just too much busy work if you ask me. You end up spending a bunch of time chasing failing specs, and your code to test ratio will besomewhat inaccurate at the end.
So what should you spec? Well let’s start with the controller. I generally use rspec_controller instead of scaffold since it does not generate an ocean of framework specs. All I really test in the controller are new methods I write, for example, a search or order method. Important sidenote: if a controller method is broken, write a spec for it and watch it fail, when you fix it and the spec passes you will know if that method ever goes belly up again.
The views can also be a pain. The rspec scaffold creates a ton of view specs based on the scaffolded view, which is generally really unlike the real view you will end up with in your app. I generally stay away from those puppies and only write view specs for important components I’d expect the view to either have or not have such as, admin links.
If you follow the skinny controller fat model golden rule, your model should contain most of the application logic. This is where your specs will rule. Make sure you have high coverage for all methods in your model. Hopefully they will do most of the heavy lifting; these should be well spec’out.
Really spend the time to spec your helpers. They will most likely be used numerous times in your application and this will save you a ton of time otherwise spent chasing bugs.
In closing, check you test coverage with rcov.
gem install rcov
rake spec:rcov
This will generate a coverage report in /coverage.
You can also run rake stats to get your code to test ratio. If you follow the above guidelines, you should expect to see something close to 1:1 or less since you are not spec’ing controller/routes/views as aggressively as rpec_scaffold does.
If you find your model specs looking a little unDRY (repetitive) while testing the model validations, you may use a block to DRY your code.
So you can replace this:
it "should validates presence of first_name" do @user.should have_error_on(:first_name, :blank) end it "should validates presence of last_name" do @user.should have_error_on(:last_name, :blank) end it "should validates presence of login" do @user.should have_error_on(:login, :blank) end ...
With this:
%w(first_name last_name login email password_hash).each do |attrib|
it "should validates presence of #{attrib}" do
@user.should have_error_on(attrib, :blank)
end
end
Hope that helps!
PS. “have_error_on” is not standard in rSpec, but only a helper method.