0

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?

Alexander Presber
  • 6,429
  • 2
  • 37
  • 66
  • imaging `posts` is used somewhere in your app and somebody removed `has_many :posts`, without test you won't know there is problem until your app crashes. – Thanh Jun 21 '17 at 12:01

1 Answers1

0

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?

Francesco Boffa
  • 1,402
  • 1
  • 19
  • 35