sfeley at gmail.com
Thu Feb 19 00:31:13 EST 2009
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
describe User do
@this = User.make_unsaved # I use machinist for my factory methods
it "is valid" do
it "can save" do
it "requires a login" do
@this.login = nil
it "may have a password reminder" do
@this.password_reminder = nil
it "does not allow duplicate logins" do
@that = User.make(:login => "EvilTwin")
@this.login = "EvilTwin"
...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.
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
Steve Eley (sfeley at gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
More information about the rspec-users