We are currently using thoughtbots shoulda gem mostly to spec functionality of our rails models.
It appears that a lot of the matchers that shoulda provides are actually testing rails behaviour. E.g.
describe Blog do
it { should have_many(:posts) }
end
just tests that this code from the model definition
class Blog < ActiveRecord::Base
has_many :posts
end
actually works.
Isn't this testing rails behavior (as opposed to the behaviour of our models)? Isn't this something to avoid generally?
This kind of question can easily derive into a flame war, but anyway, I'll give my two cents.
I do use shoulda matchers most of the times, and I agree with you that these kind of tests may look superfluous at first. So why do I keep using them?
When you're doing BDD, you are not testing the single units, but you're actually testing an object Behavior. In my point of view knowing that a Blog entity responds to a posts method with a collection of many posts, is part of the behavior of the Blog class. So I want to test it.
Further, if you follow the TDD cycle strictly, you cannot theoretically add the
has_many :posts
line without violating the principle that you should write a test first.
As in many other areas, the definitive answer depends on the project. If you have a large project with many models (or a project that is growing to be such), you may really want to test the interfaces.
If you just have a Post model with an Author, it may look like an overkill. But in this case it would cost you something like 4 lines of test... so why not?