I’ve been working on a project using Rails lately, and one of the most challenging things about it has been trying to make the tests run efficiently. Unfortunately, there’s so much setup to get the Rails environment going that simple little unit tests take about 5 seconds to run. Of that 5 seconds, it takes about 4.9 seconds for the Rails environment, and 0.1 second for the test itself. So naturally we want to use tools like Spork that will let us load up much of the common setup, and then just fork() each test to make sure it runs in a “pristine” environment. However, this gets really tricky when you are trying to both maximize how much code is loaded pre-fork() and maximize your ability to iterate on the code while keeping Spork alive. We found it all too easy to get into a state where just starting up the Rails environment loaded all of our models and controllers, and many of their attendant support classes. So of course any time you changed one of those pre-loaded classes, the change would not be reflected the next time you ran a test – unless you killed and restarted Spork, which squandered any time benefit you might get from using it in the first place.

Read More »