[rspec-users] Should(not?) test associations (was: Dealing with dependent data)
dchelimsky at gmail.com
Sat Jun 28 05:32:07 EDT 2008
On Jun 27, 2008, at 9:55 PM, Jim Gay wrote:
> On Jun 27, 2008, at 10:07 PM, David Chelimsky wrote:
>> An association does not want you to know that it's an association.
>> It wants you to think of it as any other attribute. Why do you care
>> what it IS? Focus on what it DOES.
> Good point. Being a newbie I sometimes find myself where I *think*
> I'm doing it well, but find out that it's not quite that good
There's a great bit of advice in The Inner Game of Tennis that
suggests that judging your progress with statements like "I'm doing
well" or "I'm doing badly" is counter-productive; that it's more
productive to think in terms of observing whether your actions get you
to your goal and adjusting based on your observations.
You're doing fine.
>> My opinion is that attributes and associations are equally about
>> structure, not behaviour. The fact that a project has an owner is
>> not behaviour. The fact that the owner has an email address is not
>> The facts that you can't save a project without an owner, and you
>> can't save an owner without a valid email address are behaviour.
>> And by setting expectations around those, the attributes and
>> associations themselves are handled implicitly:
>> describe Project do
>> it "should not be valid without an owner" do
>> Project.new(:owner => nil).should_not be_valid
>> Watch that fail saying that Project does not respond to 'owner='
>> method. Add a migration and an association. Now it fails saying
>> that it was valid. Add the validation and watch the example pass.
>> That's TDD (yes, starting with a T).
>> Any time I have a an attribute or an association that I *think* is
>> supposed to be on a model, I try to think of what might be
>> interesting about that attribute or association and set
>> expectations about that.
>> There are many who believe that we should have examples like
>> "project.should have_one(:owner)." I can't say that those people
>> are wrong if doing that is adding value to their process and
>> helping them deliver quality software. For me, personally, it's
>> just unnecessary noise that adds maintenance burden later when
>> things move around. And it definitely ain't behaviour.
> Thanks for the response. Perhaps I'm over thinking things. I agree
> that "project.should have_one(:owner)" is unnecessary.
> Somewhere the ideas get mangled for me.
> Suppose a simple spec like this:
> Project "should not be valid without a name"
> Owner "should not be valid without a name"
> How do you spec that the Owner may have 0 or more projects?
Again, structure. Why do you care? Does an owner behave differently if
there are 0 projects or more than 0? Is there a maximum number of
projects? Maybe projects should be tagged and you want to be able to
get an owner's projects by tag? Now THAT's interesting behaviour that
you can write examples for.
> Owner "should be valid with 0 projects"
> Owner "should be valid with more than 0 projects"
> Or would you combine them
> Owner "should have 0 or more projects"
> Or should I not care at all about that and just specify that a
> Project "should not be valid without an owner"?
I'm beginning to regret the validity example, because it is somewhat
structural as well. The behaviour is not whether it's valid or not,
but rather whether you can save it or not. So scratch the example I
gave earlier and think about this:
describe Project do
describe "when trying to save" do
it "should complain if it has no owner" do
Project.new(:owner => nil).save!
(Zach Dennis - this nesting structure should make you happy :) )
That make a bit more sense?
One key aspect of BDD is working Outside-In. I try to start with a
story and to drive things down from the view to the model (in Rails).
So maybe my story is that as an owner I can edit my projects, but not
other people's projects. This is going to naturally lead me towards
examples that will implicitly cover the fact that an owner can more
than 0 projects without actually specifying that directly.
More information about the rspec-users