Forum: Ruby unit testing rails model validation? - why bother? what's ra

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D5df9fcd7ef4c3c937435d7d6adeab2a?d=identicon&s=25 Greg Hauptmann (Guest)
on 2007-06-11 08:16
(Received via mailing list)
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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-06-11 14:18
(Received via mailing list)
On Jun 11, 2007, at 1:16 AM, Greg Hauptmann 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 Gray II
1c0cd550766a3ee3e4a9c495926e4603?d=identicon&s=25 John Joyce (Guest)
on 2007-06-11 19:36
(Received via mailing list)
On Jun 11, 2007, at 1:16 AM, Greg Hauptmann 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.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2007-06-12 10:27
(Received via mailing list)
On Jun 10, 2007, at 23:16, Greg Hauptmann 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/
This topic is locked and can not be replied to.