On Wed, Feb 18, 2009 at 11:31 PM, Stephen Eley <sfe...@gmail.com> wrote: > On Wed, Feb 18, 2009 at 10:42 PM, Mark Wilden <m...@mwilden.com> wrote: >> On Wed, Feb 18, 2009 at 4:39 PM, Fernando Perez <li...@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 (sfe...@gmail.com) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
