Unit testing rails model validation? - why bother? what's ra

Hi all,

Is there any need to write unit test cases for model validation when
such
validation is implemented by a single rails validate_* line in the
model?
e.g. “validates_presence_of :email”.

Conservatively I would say ‘yes’ however applying the following
arguments
below I’d actually re-consider and say ‘no’:

[1] Any test should clearly have a clear objective in terms of what it
is
trying to test. In this case what is really being tested in the rails
framework “validates_” command and associated rails framework that
handles
this. If you take this as already been tested as part of the Rails
release
process then there is no reason to focus re-testing this. In other
words
why write a test for a situation for which you wrote no code yourself.

[2] Any DRY? - By writing test cases you are really breaking the DRY
(don’t
repeat yourself content) by everytime you put a simple rails framework
line
(i.e. a validates_* in a model) you have to put extra straight-forward
lines
in test cases. Also would such test cases focused at testing such Rails
commands already be present in the rails code base.

Comments? What’s best practice here. Should we be writing test cases
for
such cases?

Greg

On Jun 11, 2007, at 1:16 AM, Greg H. wrote:

Is there any need to write unit test cases for model validation
when such
validation is implemented by a single rails validate_* line in the
model?
e.g. “validates_presence_of :email”.

It doesn’t have anything to do with how easy it is to implement.
It’s about validating your business logic. If a client tells me, “An
email address is required,” writing that test ensures I’m meeting the
specification.

It’s also plenty common to add a custom validation method or two,
which generally require more than one line of code. Surely you would
want to test those.

Finally, I’ve occasionally had tests show an unexpected interplay of
many validation rules. Things like that are what unit tests are so
good at uncovering.

James Edward G. II

On Jun 11, 2007, at 1:16 AM, Greg H. wrote:

below I’d actually re-consider and say ‘no’:
why write a test for a situation for which you wrote no code yourself.

Comments? What’s best practice here. Should we be writing test
cases for
such cases?

Greg
Yes, yes and yes.
Unit testing is the best way to ensure your results are what you
expect them to be. Unit testing can of course be as exhaustive or
minimal as you like.
Better to create them and run them now than to rely on faith.
Especially when it comes to data originating from external sources.
Unit test like mad to make sure it is sanitized.

On Jun 10, 2007, at 23:16, Greg H. wrote:

[1] Any test should clearly have a clear objective in terms of what
it is
trying to test. In this case what is really being tested in the rails
framework “validates_” command and associated rails framework that
handles
this.

No. You need to assert that you have validates_presence_of :email in
your model.

If you take this as already been tested as part of the Rails release
process then there is no reason to focus re-testing this. In other
words
why write a test for a situation for which you wrote no code yourself.

You don’t need to exhaustively test it, only assert the failing case.

[2] Any DRY? - By writing test cases you are really breaking the
DRY (don’t
repeat yourself content) by everytime you put a simple rails
framework line
(i.e. a validates_* in a model) you have to put extra straight-
forward lines
in test cases. Also would such test cases focused at testing such
Rails
commands already be present in the rails code base.

Your implementation shouldn’t repeat itself, your tests shouldn’t
repeat themselves, but if your tests repeat your implementation,
that’s probably ok.

Your tests are your project’s safety net. If you don’t have a test
for a line of code I can come along and delete it and not know I
broke something. Broken software sucks almost as much as falling off
the high wire with a half set-up safety net.

PS: If you don’t want to wait for me to delete the line of code, run
heckle. It’ll delete it for you.

http://seattlerb.rubyforge.org/heckle/