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.prefork do 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:
require 'vendor/plugins/thinking-sphinx/lib/thinking_sphinx/configuration.rb' Spork.trap_method(ThinkingSphinx::Configuration, :load_models)
Bonus tip: Using machinist? You better require your blueprints in .each_run or you might see all sort of weird behaviour.
This is either awesome or incredibly stupid. ...
If you’re anything like me, you’re not only strikingly handsome but also in a weird love affair with the idea of validating an arbritarily deep hierarchy of HTML tags from within cucumber. Like when oh I don’t know.. Say you have an ul like so:
<ul> <li><a href="/a">A</a> <ul> <li><a href="/a/1">A.1</a> <ul> <li><a href="/a/1/1">A.1.1</a></li> </ul> </li> </ul> </li> <li><a href="/b">B</a> <ul> <li><a href="/b/1">B.1</a></li> </ul> </li> </ul>Then you want to be able to write the following steps:
Or maybe you don’t. But at least after drinking some Mac Queen’s Nessie Whisky Malt Red Beer, I for one certainly did.. Also: working with Nokogiri & XPath can be oddly ruminant!
And here it is, the (soon-to-be) patented prototype implementation of said (possibly stupid) awesomity: