Posted by
Justin on
Friday, January 25
When working on model specs with rspec, it helps to have a hash of valid attributes for the model you're working with. This makes it easy to spec validations, save valid records when needed, etc. I used to use the method in this excellent peepcode of creating a helper module in the same file as my model spec. For example, if I was spec'ing a User model:
# The way I used to do it...
# In spec/models/user_spec.rb:
module UserSpecHelper
def valid_user_attributes
{ :username => "user", :password => "pass" }
end
end
describe User do
include UserSpecHelper
...
That worked great, until I started wanting to spec complex associations, interactions between models, etc. In many cases I needed valid records of multiple different models. At first I simply moved the helper modules into external files that were required in spec_helper. That soon became cumbersome as I was including many modules in many different describe blocks. It just seemed like a lot of extra code simply so everything could stay pretty and proper and namespaced. So I said screw it, what's the harm in making these all top-level methods? And started throwing them directly in spec_helper.rb:
# The way I do it now...
# In spec/spec_helper.rb
...
def valid_user_attributes
{ :username => "user", :password => "pass" }
end
def valid_biscuit_attributes
{ :butter => true }
end
...
Now I can get a hash of all valid attributes for any model in any of my specs. This probably isn't the bestest most proper way to go about it, but it makes me happy.
Tags: rspec
Meta:
0 comments,
permalink
Posted by
Justin on
Wednesday, December 12
I'm never quite sure what the best way to write specs for assocations is. This is how I usually do it:
describe Butter do
it "should belong to a biscuit"
butter = Butter.new
biscuit = Biscuit.new
butter.should respond_to(:biscuit=)
butter.biscuit = biscuit
butter.should respond_to(:biscuit)
butter.bicsuit.should == biscuit
end
end
Really I'm just asserting that Butter has a biscuit attribute that I can use to set and get a Biscuit object. I do pretty much the same thing for all of the association types. I never really test that the association is actually a belongs_to association, or a has_one association, or any of the other types. But I'm not sure I actually WANT to test for that. Because that's technically not behavior, that's implementation. I'd just be testing rails internals instead of writing a spec for how my app should behave. Am I making any sense...?
Maybe the issue is the terminology I'm using. I considered saying "should have a biscuit attribute", but that felt... wrong. If I do that I might as well spec out all my attributes, and that is lame.
I also sometimes have a problem with the "should" terminology for associations. If I say "should belong to a biscuit" it seems to imply my object would be invalid if there was no biscuit object assigned, but that's not always the case. I considered "can belong to a biscuit", but... I just don't know.
I'm going to pretend like I have an actual reader-base and ask... any ideas?
Tags: rspec
Meta:
4 comments,
permalink
Posted by
Justin on
Friday, November 30
I've been loving Behavior Driven Development pretty hard. This post made me think of the way I usually approach it, which led to a deep inner need to document that approach...
Tags: rspec
Meta:
0 comments,
permalink