Marnen Laibow-Koser wrote:
>>> def setup
>>> @valid_blog = Blog.new(valid_blog_attributes)
>> Don't construct a blog - fetch one from the fixtures:
>>
>> @valid_blog = blogs(:valid_blog)
>
> Why? In my experience, fixtures make tests brittle and hard to
> understand, so I've stopped using them entirely. What's the advantage
> here?
(Let's hope you have not replaced them all with totally empty mocks!)
The advice for newbs, and possibly also for the original poster, is to use
fixtures the way the tutorials specify. This gets them out of the starting gate.
The advice, as a project grows, is to use some form of "scenarios", which are
kits of fixtures tuned to specific situations. Example: new_customer,
paid_up_customer, delinquent_customer, etc.
If you don't use raw fixtures, you should find yourself implementing a scenario
system directly into your setup blocks. From there, you should re-use their
support methods into some scenario library.
Finally, I suspect the most advanced advice possible is to always write
assertions that gracefully adapt to your data records, whether they be classic
range-free fixtures, or isolated scenarios. Don't do this:
records = get_fithy_records()
assert{ records.length == 17 }
That breaks when you add a new filthy record, for whatever reason! Instead, do
this:
assert{ records.map(:status).uniq == ['filthy'] }
This link emblogs the ideal of writing flexible tests, even when your code
happens to implement something complex, such as a Minimum Spanning Tree:
http://broadcast.oreilly.com/2009/02/merb-mind-maps.html
>> As you get better at testing, you will get bored with testing that
>> ActiveRecord
>> behaves as advertised, and you will test your actual logic.
>
> Yeah. ActiveRecord has already been well tested. Focus on the code
> you wrote.
>
> (I know, that's a tough concept to internalize -- I certainly don't
> always manage...)
When you are getting started with a new library, writing unit tests directly on
the library is a best practice. So, you should indeed precede "Foo.has_many
:bars" with a test that a foo object has a .bars collection full of bars.
--
Phlip
http://flea.sourceforge.net/resume.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" 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/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
