[rspec-users] validate_presence_of

[Mike Gaffney]

Dave, you make a good point. In our system, where we are converting a 
legacy database/application, we typically have no user stories and have 
the technical (or you could argue user) requirement that the database 
logic / constraints get converted. This is where we are typically just 
encoding all of the should_have_many, etcs. They at a first glance do 
seem like fragile and redundant tests but when you consider that the 
schema isn't in rails standard format, simple has_manys are not always 
going to work so we actually need to test our configuration of the 
associations.

-Mike

David Chelimsky wrote:
> 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!
>
> Cheers,
> David
>
>   
>> --
>> 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
>>
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>   

-- 
-Mike Gaffney (http://rdocul.us)