What are people’s thoughts on unit testing in the model? I was
looking through the RoR manual[1] and it showed some examples of
testing CRUD operations. Does this make much sense? Aren’t you just
testing ActiveRecord and Rails at this point?
If you are interested in testing your validation rules you could have
something like …
assert @foo.validate
Why actually test the persistence to the database? When using Java
and Hibernate I would test the actual persistence but that was so I
could test the actual mapping configuration. I suppose with Rails you
can still check if the associations are mapped correctly (such that
they are actually persisted.)
What else should one test in models? Other then validation the other
good candidate seems to be class methods.
What else should one test in models? Other then validation the other
good candidate seems to be class methods.
I agree. I think some of that is just examples. In general I test my
code, not the code my code depends on. I rely on other people to test
their code (and if they are not testing enough then I might consider
adding a test to their code but I would not add a test for their code in
my testing). In the model things I test often:
Complex validation (things like validates_confirmation_of again I rely
on Rails to test that. I just test custom validation stuff)
Custom finders. So if I have a “find_active” method that finds all
active records I make sure an inactive record is not included.
Custom Logic. So if I have a “mark_completed” method I make sure that
updates the fields correctly
Basically I test the code that I wrote. If my code is just declarative
and other code is actually implementing the functionality I don’t
usually test that.
Basically I test the code that I wrote. If my code is just declarative
and other code is actually implementing the functionality I don’t
usually test that.
Someone on the Seattle.rb mailing list pointed out what I thought was
a compelling and simple question for testing things like validations:
Does your test break if you remove the validation code?
The point isn’t to test that Rails validations work - I think you’re
right about not testing other people’s code in that sense. But if you
can remove critical code from your model, and your test passes, then
your test isn’t complete.
This probably came up in the context of a Heckle mutation tester
discussion:
What else should one test in models? Other then validation the other
good candidate seems to be class methods.
CRUD.
Anything a user can do thru the GUI, a programmer can do, nearly the
same
way, with the models. Suppose that updating a customer record requires
all
the matching account records to change their state. If a user does this,
they hit the Update button on their form (the U in CRUD), then they go
to
the account page, and all the records have a new status.
If a programmer does this (via a unit test, or the console), they call a
method on the Model object with the same parameters as that form had.
Then
when they query account records, these all have the matching update.
Put another way, Controllers should have no business logic. They should
not
even intermediate between Model objects. All business logic should
reside
only in the Model.
Basically I test the code that I wrote. If my code is just declarative
and other code is actually implementing the functionality I don’t
usually test that.
Someone on the Seattle.rb mailing list pointed out what I thought was
a compelling and simple question for testing things like validations:
Does your test break if you remove the validation code?
Another perspective is: You’re not testing the Rails validation code,
you’re testing your usage of it. It’s not hard to write a piece of code,
which seems really simple and yet when writing a test one finds that it
isn’t working as expected.
–
Cheers,
Jacob A.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.