My answer is:
Depends,
if you or your team uses Houlda-matchers, as quoted in another response, test
validations becomes something trivial, so test.
However, I believe that Shoulda-matchers is an unnecessary dependency and you do not need to test 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 by misspelling the field name, which I believe is something easy to observe.
But imagine a case where validation depends on a reasonably complex regular expression, for example to validate a phone number. In this case, as the code is not so trivial it would be interesting to have case tests for more common valid and invalid phones and even some exceptional cases to ensure.
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’s worth testing.
Watch Alexandre Freire’s lecture, 'What not to test' to better understand:
http://www.infoq.com/br/presentations/o-que-nao-testar
Many people will say that you should test everything and should have 100% coverage. I would say that the right thing is to test what is important for your application: its business logic and things that have not been tested by the development of the framework.
That is, one should test the maximum logic that does not depend on the framework. And the assurance that the framework works should be in the high-level (integration) testing, which will not test all the code but will serve as a health test to ensure that the parts work together and that the framework plays its role.
Yes, defining validations is fundamental, otherwise we would have to use
try/catch
to treat errors. As for testing validations, it may be more necessary if you don’t want to define contraints at the bank.– user7261
Validating the model also helps with performance issues, as it avoids overloading the network and database server with something that could have been checked earlier.
– utluiz
@utluiz I don’t think the performance gain would be noticeable in most cases (but this is more my kick than experience). Besides, if the system is web, the validation will be done on the server anyway. And there are important reasons to create constraints at the bank.
– user7261
@Andrey You are considering simple cases, such as criminal records. Even so, the overhead to open connection and transfer data between the application process and the database process can be large if several consecutive operations are performed. If you are entering, for example, 72 installments in the database of a financing operation and the latter has a problem, the time will be very noticeable, since the system will have opened a transaction and inserted data in several tables, created several Locks and transfer transaction data plus 72 tranches.
– utluiz
My concern is that we are always too optimistic about "it won’t affect performance so much". I thought so too, until one day I had to turn a system used in several resales upside down because it was giving timeout. Only with some "beasts" optimizations could I reduce the time by 90%, because little by little the "not perceptible" became practically unbearable.
– utluiz
Another problem that can occur is if there is high competition, that is, many users. Leaving validation to the bank also means opening an unnecessary connection in many cases. Of course each system is different, but it is good to think twice before assuming that there will be no competition problems, especially if the system is used online. However, if it is an internal system I agree with you~e.
– utluiz