What is considered a good spec? Rspec examples for beginners - ruby-on-rails

Question

What is considered a solid spec?
This is what I find to be very abstract about testing. I'd be interested in the answer for this on models, controllers and whatever else can be tested. It would be cool to have a spec for a spec, you know what I mean?
A model spec should (in order of priority and relevance):
Test all methods?
Test errors array?
Test CRUD (and how)?
What else?
A controller / view spec should (in order of priority / relevance):
Fill in the blank...
?
Would be great to expand this list of what a spec should and shouldn't contain.
I'd also like to compile a list of tricks and suggestions as well. For example:
The keyword "should" is sorta redundant.
Example:
this:
it "should be invalid without a firstname"
would be better as:
it "is invalid without a firstname"
Yet another trick, use expect instead of lambda for readability:
lambda { ... }.should be_valid
is more readable as:
expect { ... }.should be_valid
I am compiling a list of helpful articles on getting started and will share those in this post as they come along. Here are some that I'm finding particularly helpful as of now. (Feel free to post yours and I'll tack it on if it seems helpful).
http://everydayrails.com/2012/03/19/testing-series-rspec-models-factory-girl.html
http://nelvindriz.tumblr.com/post/835494714/rspec-best-practices
It would be great to have a list of projects where tests are implemented well. Since rspec is so readable (at least that's what everybody says), it would be great to get a list of links to projects that have great specs to read.
"See the Mongoid specs for an example of good specs." -#yfeldblum (see answer below)
Online you'll find a lot of articles describing unrealistic scenarios on how to test basic stuff, but beyond that you're sorta on your own. If I were to write an article on this topic I would just link to my tests (on github for example), then thoroughly annotate one or a few of those specs... this seems like the best way to write an article on rspec, in my opinion. I'd do it myself, but I'm not quite there yet.
If you vote to close this, that's fine, just try to leave a comment or suggestion on where you think this post would belong. Thanks!

Answer 1

This is actually a good question because when I started out with test cases, I wasn't sure what is considered a good test case. Here are a few things which you can follow. This list is not mine; but compiled from a few sources plus some of my additions.
Describe methods
While describing methods, it is a good practice actually describe your method like: describe "#admin?" etc. "." is a prefix for class method and "#" is a prefix for instance methods.
One assert per test case
Make sure that you have just one assertion per test case. This makes sure that your test cases are clean and easy to understand; which is the point of test cases, isn't it? :)
Avoid saving data to db
You can dynamically build objects to and avoid saving data to db. Although you can clean up the db before each test case, "not saving" will speed up test cases in a big way.
#user.build(:something) instead of #user.create(:something)
Edge and Invalid cases
This is not specific to Rspec but it is important to make sure edge cases are covered in testing. This helps greatly later on when your project grows and it gets easy to maintain.
contexting
I, personally, like this a lot in Rspec and I in fact overuse contexts a bit. Using contexts with conditions helps in compartmentalizing your test cases. Here's an example:
# Avoid
it "should have 200 status code if user is logged in" do
response.should respond_with 200
end
it "should have 401 status code if user is not logged in" do
response.should respond_with 401
end
# Use
context "when user is logged in" do
it { should respond_with 200 }
end
context "when user is logged out" do
it { should respond_with 401 }
end
Using subject
When you have lots of test cases which are related to the same thing, you can use subject() to make sure you don't repeat yourself.
# Avoid
it { assigns(:user).should be_valid }
it { assigns(:user).should_not be_dumb }
it { assigns(:user).should be_awesome }
# Use
subject { assigns("user") }
it { should be_valid }
it { should_not be_dumb }
it { should be_awesome }
Here are a few things that I try to follow when I write test cases. I'm sure there are a lot more things which can improve Rspec test cases. But this should be enough to get started and write awesome test cases.

Answer 2

See the Mongoid specs for an example of good specs.
Have exactly one assertion per example. Do not assert two things in the same example. An example is the block passed to it, its, or specify.

Answer 3

I'm following a tutorial to learn Ruby on Rails, and it's teaching Rspec as part of test-driven development. The flow here is to write a test that fails, write code to pass the test, and then pass the test. The rationale seems to be that by doing this—by starting with a failing test—you can be pretty darn sure that your code does what you expect. So I suppose a good spec is one that ensures that your code does what it's supposed to. As of yet I haven't gleaned any rules of thumb from the tutorial like the other posters have written, though.
Here's the link: http://ruby.railstutorial.org/

Answer 4

When you are writing your controller tests you want to cover with tests all your actions in your controller.
Example how tests for controller actions should look like:
describe "Stories" do
describe "GET stories#index" do
context "when the user is an admin" do
it "should list titles of all stories"
end
context "when the user is not an admin" do
it "should list titles of users own stories" do
end
end
describe "GET stories#show" do
it "should render stories#show template" do
end
end
describe "GET stories#new" do
it "should render stories#new template" do
end
end
describe "POST stories#create" do
context "with valid attributes" do
it "should save the new story in the database"
it "should redirect to the stories#index page"
end
context "with invalid attributes" do
it "should not save the new story in the database"
it "should render stories#new template"
end
end
describe "DELETE stories#delete" do
it "should delete the story from the database"
it "should redirect to the stories#index page"
end
end
You can find out more about controller tests here.