Things I learned about fixtures the hard way
Wednesday, February 27th, 20080. “rake db:fixtures:load” will empty your dev db and fill it with your fixture data. If you’re wondering what’s going wrong with your fixtures, this can be a huge help.
1. The AR fixtures code does not check to see if a record is valid before inserting it. And it only checks validity on save (mostly), so it’s quite possible to get an error in testing (but not dev) that’s due to an invalid fixture record.
If you can’t get something to work quite right, it may be due to a bad fixture, and your code and test may be correct. Something as simple as an omitted field in a fixture you haven’t touched can be enough to ruin your whole afternoon.
2. Another thing that doesn’t check for validity is Foo.delete_all. This is a quick and easy way to kill referential integrity. It’s generally a bad idea in tests, even if you’re using transactional fixtures.
3. With new “foxy fixtures”, you can say “mission: foo” to hook mission_id to foo[:id], but this doesn’t work through a belongs_to link that uses :foreign_key. I mentioned it to somebody at seattle.rb who claims to work with Fixtures Guy, so maybe it’ll get fixed someday.
Foxy fixture links aren’t checked for validity, either, BTW. It just hashes the name you pass, so if you say “mission: bogus”, and there’s no mission fixture called “bogus”, it’ll still insert a value, and you’ll get a weird error. (Or worse, “mission: threee”.)
4. (Not related to fixtures at all) In Rails, “.” in a (URL) path is a “route separator“, so it doesn’t behave like you expect by default. The fix is to add something like:
:requirements => {:id => /[a-zA-Z0-9_@\.]+/}
to the map.connect call in routes.rb.
