On 10/09/2011, at 4:49 PM, Brian Guthrie wrote:
> Association existence probably isn't all that helpful, but once you
> start to use some of the more arcane options then it really, really
> helps to have tests around them. I've been burned before by
> associations that weren't really working the way I expected them to
And that's why I said "usually" :D If you're doing something complex, and need
to confirm behaviours in certain cases, then sure, test away. You should
certainly be testing association extensions, but vanilla associations? Not
necessary.
> (some of the more arcane flags in has_many :through, for example), so
> now as soon as I get more complex I start covering with tests. TATFT
> and all that.
Yes, but it's TATFT, not Test Every Fscking Thing :) Tests should be subject to
the YAGNI rule too.
>
> I thought the suite was a good starting point--better to be more
> conservative. :)
>
Belts and braces... it doesn't hurt.
> My one comment--and I think popular opinion has swung against me
> here--is that I don't love the extensive use of the setup block. I
> vastly prefer
>
> Artist.new.releases.should be_empty
>
> to
>
> setup { @kanye = Artist.new }
>
> @kanye.releases.should be_empty
>
setup blocks and instance vars can be replaced by using the "let" syntax in
rspec, eg:
describe Artist do
let(:kanye) { Artist.new }
it "should have no releases" do
kanye.releases.should be_empty
end
end
Using this form, kanye is lazily evaluated (ie Artist.new is not called until
the first use), which is why there is a let! method as well, which will
evaluate the block immediately.
You can go a step further though, and use rspec's implicit subject:
describe Artist do
its(:releases) { should be_empty }
end
> The closer the definition is to the assertion, the better.
>
> One last suggestion, not really related to your suite - I don't know
> what FactoryGirl does by default these days, but I prefer initialize
> or stub to create if I can, and only use create if the test really
> relies on the existence of a record. Keeps the suite faster.
This is a good point, although if you use the build strategy of factory girl,
you're responsible for ensuring that your factory is generating valid
instances, afaik. This isn't a bad thing, it's just something to be wary of.
Cheers,
W.
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
