[rspec-users] validate_presence_of

David Chelimsky dchelimsky at gmail.com
Thu Feb 19 00:58:19 EST 2009

On Wed, Feb 18, 2009 at 11:31 PM, Stephen Eley <sfeley at gmail.com> wrote:
> On Wed, Feb 18, 2009 at 10:42 PM, Mark Wilden <mark at mwilden.com> wrote:
>> On Wed, Feb 18, 2009 at 4:39 PM, Fernando Perez <lists at ruby-forum.com> wrote:
>>> What's the point in testing validates_presence_of for a model?
>> To make sure you wrote that line of code.
> And the circle spins round and round...
> Specs that mirror the code that closely are a bad idea, I think.  The
> problem with that example is that the syntax of the code is driving
> the syntax of the spec, even if the spec was written first.  You're no
> longer thinking about high-level behavior, you're thinking about the
> presence of a certain line in Rails.
> I write those sorts of model specs a little differently.  I just poke
> at things and set expectations on whether they break.  I'd write this
> example like:
> describe User do
>  before(:each) do
>    @this = User.make_unsaved   # I use machinist for my factory methods
>  end
>  it "is valid" do
>    @this.should be_valid
>  end
>  it "can save" do
>    @this.save.should be_true
>  end
>  it "requires a login" do
>    @this.login = nil
>    @this.should_not be_valid
>  end
>  it "may have a password reminder" do
>    @this.password_reminder = nil
>    @this.should be_valid
>  end
>  it "does not allow duplicate logins" do
>    @that = User.make(:login => "EvilTwin")
>    @this.login = "EvilTwin"
>    @this.should_not be_valid
>  end
> end
> ...And so forth.  It's wordier, but very readable, and it doesn't rely
> on the validation being done with a specific Rails method.  In fact,
> when I shifted to using Merb and Datamapper, I didn't have to change
> these sorts of tests at all.

That's huge!

> Also, while I used to be very anal and write "should
> have(1).error_on(:login)" and such, I eventually realized that there's
> no point.  Checking on 'valid?' is entire and sufficient.  The first
> example proves that the default factory case is valid, so as long as
> we're only changing one thing at a time, we know that that's the thing
> that breaks validity.  (Or, in the case of "may have," *doesn't* break
> validity.)

I think this depends on whether or not error messages are part of the
conversation w/ the customer. If not, that seems fine.

I find that I'll spec validations directly, but not associations.
There's no need to say that a team has_many players when you have
examples like team.should have(9).players_on_the_field.

But my validation specs do tend to be closely tied to AR methods like
valid?(), which, as your example suggests, is impeding my ability to
choose a different ORM lib. Time for some re-thinking!


> --
> Have Fun,
>   Steve Eley (sfeley at gmail.com)
>   ESCAPE POD - The Science Fiction Podcast Magazine
>   http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list