Jake Scruggs

(Or the downside of class caching) This is a gotcha in Rails where your custom plugin or other dynamic change of a class only seems to work once. First, a little background: Recently we had a problem where we wanted an object to behave differently in two different instances of Rails. Ya see, we have models that are shared by two separately running rails instances. One is a cms (content management system) where all objects (let's say they are of class Thing) should show up. The other is the live site that should only show 'things' that have been designated 'live' (as opposed to, say, 'draft'). Now changing the search to filter out non-live 'things' was easy, but since you can call thing_instance.related_things and get back related objects of type Thing, now we have a problem. In the live site I want a call to 'related_things' to only bring back 'live' objects. But in the cms I want the same call to 'related_things' to bri...

(This is the third of three posts on Rails fixtures) Awhile back Josh Cronemeyer approached me with an idea to migrate fixtures in Rails. The problem we were trying to solve is when your database changes you need to edit all the fixture files to reflect the change – which usually doesn't happen and then things break/get weird. We spent a few hours hashing out the basic plan (load all the fixtures into the db, migrate, then write the db out to the fixture files) and writing some code. Then he went off, tested it, and made it work with (very) occasional input from me. He's written up a nice post on the topic called How to Migrate Fixtures in Rails and has posted the code at Google Code . Go check it out if you hate migrating fixtures by hand.

(This is the second of three posts on Rails fixtures) I like using fixtures for setting up a development environment. Applications need data in the db to function so what most teams do is pass around a database, or two, or five. A new person joins the project and he/she gets a dump from one of the devs, imports it and goes to work. What happens when you screw up your db by: Running a bad migration Importing a crap load of data for a task (I remember once filling up a db with all movies playing in North America) but later you don't need it. Doing something dumb. (my personal favorite) Well, you need to get somebody else's db. Which maybe in a bad state and it definitely doesn't have the same data you're used to because they've been changing it a lot. But if you have a bunch of fixtures checked in to source control, you can always go back to a base state. Anytime something is acting wacky and you think it might be a data problem (which happens more and more as th...

(This is the first of three posts on Rails fixtures) So you have a Person object that has a many to many relationship with Roles and Movies (maybe this is site where people track their favorite movies). So to test it you need to have the following files: people.yml roles.yml movies.yml and the join tables: people_roles.yml movies_people.yml If you want to test that only people of a certain role can edit another person's favorite movie list, then your test is spread out amongst 7 files (don't forget the test file and the actual class file). Maddening enough when you're writing it, but super crazy insane to debug when the test breaks. More than likely a developer will delete/comment out the the test when it breaks, or they will change it so passes but breaks functionality. Long tests that repeat themselves look bad, from a DRY (don't repeat yourself) point of view but consider this: A fixture that is useful for 10 tests tells you nothing about any one test. Many time...