matt-lists at reprocessed.org
Fri Feb 29 14:08:26 EST 2008
I've been playing with doing clever(ish) reporting things by hooking
custom formatters in which do stuff (in my case, generating rspec
output linked to Scrum project management artefacts like Sprint and
I'm looking at doing the same with Story Runner stories, but I was
having real problems getting even the standard HTML story formatter
It turned out that this was because the spec/rails/story_adapter code
requires, and triggers, rspec_options (through the RailsExampleGroup
subclassing of Test::Unit::TestCase, which gets extended elsewhere).
rspec_options consumes and clears ARGV, so by the time poor old
run_options gets a look in, there's no ARGV left, so a default
Spec::Runner::Options ends up being created.
This is a problem for a couple of reasons. One, it's serious voodoo -
it's the requiring, not explicit code running, that screws this up,
and secondly, it only happens (AFAICT) when you require the Rails
story adapter - vanilla non-rails Stories are fine (like, for
instance, Story Runner's own specs...).
I'm looking at ways to fix this, because it's clearly a problem. My
first thought was that run_options was a bit non-DRY, because it's
doing the same thing as rspec_options does. I decided to just use
rspec_options in its place. In practice this works fine and clears up
the problem (because the voodoo works for you). However, this makes
it almost impossible to test - I got a cascading failure, with stuff
breaking throughout the Story Runner specs.
The way that kicking off option parsing, and making its results
accessible, works is making me really nervous. Particularly, it feels
like it shouldn't be this hard to test and work with.
I don't know what other peoples thoughts are, but I'm seriously
thinking about trying to come up with an alternate way. Would people
Matt Patterson | Design & Code
<matt at reprocessed org> | http://www.reprocessed.org/
More information about the rspec-devel