So you’re using Tim Harper’s excellent Spork gem to preload your expensive environments and then run your tests in independent processes to ensure both speed and clean environments (”worlds” in cucumber lingo). And you should because who wants to wait longer for just one example group or feature to be executed than it takes you to take a sip of coffee? No one of course!
Unfortunately though, you could run into one particular problem that might defeat pretty much the whole purpose of your whole setup: rapid validation of just written code. Which obviously needs to be loaded before your test ist run. The whole value proposition (MBAs welcome on this blog! fold down your lacoste shirt collars, silence your blackberries and read right along) of spork of course is to keep never or rarely changing stuff around while reloading more volatile code on each test run.
For this you load the former in a Spork.prefork block and the latter either in Spork.each_run or your test files themselves. When using Rails, you’d usually load up the Rails environment in your prefork block as, clearly, this is the most expensive part of a test run. This is all fine and dandy until somewhere during your Rails initialisation, classes you regularly work with (e.g. models) get preloaded.
Who would do such a thing in spite of the Rails autoloading mechanism (triggered by MissingConstant)? Well, rogue plugins of course! Or maybe even yourself. In any case, this is easily fixed. Should you already know which function leads to preloading of whichever classes you’d rather see reloaded upon each test run, go right ahead and trap it:
Spork.preforkdo
Spork.trap_method(VeryEagerClass, :load_stuff)# or...
Spork.trap_class_method(VeryEagerClass, :load_stuff)# for class methods (duh..)
Very good. But if you’re anything like me, very good is not nearly good enough for you. You need awesomity! And this exactly what we’re getting courtesy of the -d / –diagnose switch. You don’t know where your volatile stuff is loaded during Spork preforking? Simply
spork -d|grep-A25"file/youre/interested/in.rb"
and you’ll be presented with nice stacktraces. Simply take a good look to find out what to trap and live happily ever after! –diagnose is especially useful when dealing with plugins whose inner workings you might not yet be familiar with. A likely candidate to mess up your sporks is thinking_sphinx which needs to be domesticated like so:
Ensure class reloading when using Spork
So you’re using Tim Harper’s excellent Spork gem to preload your expensive environments and then run your tests in independent processes to ensure both speed and clean environments (”worlds” in cucumber lingo). And you should because who wants to wait longer for just one example group or feature to be executed than it takes you to take a sip of coffee? No one of course!
Unfortunately though, you could run into one particular problem that might defeat pretty much the whole purpose of your whole setup: rapid validation of just written code. Which obviously needs to be loaded before your test ist run. The whole value proposition (MBAs welcome on this blog! fold down your lacoste shirt collars, silence your blackberries and read right along) of spork of course is to keep never or rarely changing stuff around while reloading more volatile code on each test run.
For this you load the former in a Spork.prefork block and the latter either in Spork.each_run or your test files themselves. When using Rails, you’d usually load up the Rails environment in your prefork block as, clearly, this is the most expensive part of a test run. This is all fine and dandy until somewhere during your Rails initialisation, classes you regularly work with (e.g. models) get preloaded.
Who would do such a thing in spite of the Rails autoloading mechanism (triggered by MissingConstant)? Well, rogue plugins of course! Or maybe even yourself. In any case, this is easily fixed. Should you already know which function leads to preloading of whichever classes you’d rather see reloaded upon each test run, go right ahead and trap it:
Very good. But if you’re anything like me, very good is not nearly good enough for you. You need awesomity! And this exactly what we’re getting courtesy of the -d / –diagnose switch. You don’t know where your volatile stuff is loaded during Spork preforking? Simply
and you’ll be presented with nice stacktraces. Simply take a good look to find out what to trap and live happily ever after! –diagnose is especially useful when dealing with plugins whose inner workings you might not yet be familiar with. A likely candidate to mess up your sporks is thinking_sphinx which needs to be domesticated like so:
Bonus tip: Using machinist? You better require your blueprints in .each_run or you might see all sort of weird behaviour.