My answer is:
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:
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>