Agile Zone is brought to you in partnership with:

Kevin Rutherford, PhD, is a UK-based extreme programmer and agile software coach with over 30 years professional experience. He developed the Reek code-smell detector for Ruby and co-authored "Refactoring in Ruby". Kevin is a DZone MVB and is not an employee of DZone and has posted 15 posts at DZone. You can read more from them at their website. View Full User Profile

Why I don’t use spork

08.09.2011
| 1912 views |
  • submit to reddit

Spork is great. And so is guard and its family of plugins. Early this year I spent a while converting all of my rails projects to use spork, and we even had a team standard tmux setup that ran spork in one of the start-up screens. So every time we saved a file, guard/spork ran some of our specs. We even had growl/notify pop up a little message telling us the result, so we didn’t have to go to the trouble of switching screen to find out. How very efficient!

But now I’ve turned spork off, and here’s why: Spork solves the wrong problem.

We enabled guard/spork because our specs were slow, and during the few months we had spork, those specs became even slower. But we never noticed. Most of the time guard/spork guessed correctly which specs to run, and we became quite good at configuring guard to re-load Rails when critical files changed. So we were reasonably comfortable, and our specs ran quickly most of the time. But our design was getting worse every day.

Slow specs are a sign of too much coupling, and in the case of a Rails app that usually means not enough separation between the domain objects and the adapters. So we’ve stopped running spork, so that we can feel the pain of the 15-second Rails load time, and so that we can feel the pain of all that coupling. And slowly we are making the app’s specs faster. Many spec files now run in under a hundredth of a second, and more will follow as we gradually peel domain code out from the Rails infrastructure. We don’t need to test the Rails components, and we have a very good suite of cucumber features that act as end-to-end integration tests. So our specs should be fast, and only need to tell us that our own objects each do their thing. That’s what we are now working towards, and that’s the pot of gold that spork was hiding from us.

References
Published at DZone with permission of Kevin Rutherford, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Kyane Ben replied on Thu, 2012/03/15 - 11:01am

How does your test-speed correlate to rails startup-time? Even starting up a blank Rails 3 application for test is taking about 5 seconds on each rake call! (On a brand new iMac, don’t even think about doing it on a Air…)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.