dchelimsky at gmail.com
Fri Feb 29 16:51:44 EST 2008
On Fri, Feb 29, 2008 at 1:08 PM, Matt Patterson
<matt-lists at reprocessed.org> wrote:
> Hey there,
> 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
> Product Backlogs).
> I'm looking at doing the same with Story Runner stories, but I was
> having real problems getting even the standard HTML story formatter
> to work.
> 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,
Definitely. This is something we recognized when we merged the story
runner into rspec. We just haven't had the cycles to address it.
> 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
> be interested?
Very interested in discussing. The existing set up evolved because it
made it dirt simple to spec out the option parsing itself, but the
cost we ended up with is that everything else is a challenge :) Please
do start a ticket at lighthouse and we can discuss approaches and
> Matt Patterson | Design & Code
> <matt at reprocessed org> | http://www.reprocessed.org/
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel