Is it recommended to test model validations?

My answer is:

It depends, if you or your team uses shoulda-matchers, as quoted in another answer, test validations becomes somewhat trivial, so test.

However, I believe that shoulda-matchers is an unnecessary dependency and you do not need to test either very simple validations (such as validates_presence_of) or associations. This type of code comes straight from Rails and the only way you could make a mistake in it would be to type the wrong field name, which I think is easy to see.

But imagine a case where validation depends on a reasonably complex regular expression, for example to validate a phone number. In that case, as the code is not so trivial it would be interesting to have case tests for valid and invalid most common phones and even some exceptional cases to guarantee.

This test approach also applies to scopes: if you are creating a very simple scope with a trivial query, do not write the test. However, if the scope involves complex rules and custom SQL, then it is worth testing.

Watch the lecture by Alexandre Freire, 'what not to test' to better understand: link

Many people will say that you should test everything and should have 100% coverage. I'd say it's all about testing what's important to your application: its business logic and things that have not been tested by developing the framework. That is, one should test the maximum of logic that does not depend on the framework. And the assurance that the framework works must be in the high-level (integration) tests, which will not test the whole code but will serve as a sanity test to ensure that the parts work together and that the framework plays its role. / p>     

Regarding the situation of creating tests for validations, my answer is No. This is because you will probably already be using a framework that already has tests and guarantees that these validations work.

So, avoid testing what has already been tested.

Regarding the need to define validations, I would say that it is best to define them. True, it can (and should) be created constraints in the DB itself. The difference is that if you get to the database without a mandatory value (for example), the query will give error. While you have the validations in the template, you can inform the user in a more pleasant way.

Of course, graceful errors also depend on the ORM / Framework itself.

It depends on how you are developing.

If you are doing test-driven design, ie Red-Green-Refactor it makes sense to ensure that validations exist in the model.

Using shoulda ( link ), you make testing a lot easier.

Ex:

describe Post do
  it { should belong_to(:user) }
  it { should validate_presence_of(:title) }
end