Spec::Story::Runner.run_options and rspec_options code duplication and problems
Reported by Matt Patterson | April 11th, 2008 @ 12:37 PM | in No-Milestone-Assigned
If you require 'spec/rails/story_adapter' the require chain winds up triggering rspec_options through the RailsExampleGroup subclassing of Test::Unit::TestCase (which gets extended elsewhere). The end result is that, because rspec_options consumes ARGV, Spec::Story::Runner.run_options has nothing to consume when it's invoked - so it's impossible to pass options to Story Runner if you're using the Rails story adapter.
I think that the options code needs refactoring so we can avoid the code duplication, and also I think that we need to avoid the situation where just requiring rspec_rails causes ARGV to be consumed and emptied.
As a starting point, I'm going to look at whether the evaluation of rspec_options can be avoided before rspec is asked to run specs, and whether rspec_options can be made more amenable to testing (the current approach requires some explicitly-untested workarounds).
Comments and changes to this ticket
-
Matt Patterson April 24th, 2008 @ 10:35 AM
So, I'm looking at two angles of attack here. First, splitting out the example collection stuff (rspec_options.add_example_group et al) from the option parsing bits - something like rspec_collector.
That, by itself, ought to stop things like the require-spec/rails/story_adapter-consumes-ARGV - that require chain would only be registering ExampleGroup subclasses and mixed-ins - only calling rspec_collector and not rspec_options.
The second angle is looking at how rspec_options gets called, to see if it's possible to allow easier speccing of those bits of rspec itself. I'm still looking at that. I'm going to try and get a patch in for rspec_collector later today, so people can see what I mean better.
-
Matt Patterson April 26th, 2008 @ 09:37 PM
Here's a link to a github commit that demonstrates an approach to the collection of example groups which is separate from rspec_options/Spec::Runner::Options, which uses an approach to making speccing example group collection considerably easier than the $rspec_options modding currently needed...
-
Brian Takita May 22nd, 2008 @ 10:11 AM
Matt, that patch looks nice. Why do you have the 'use_spec_collector?' boolean?
Why not just always use the collector?
-
Brian Takita May 22nd, 2008 @ 10:11 AM
- → Assigned user changed from “” to “Brian Takita”
-
Matt Patterson May 22nd, 2008 @ 01:30 PM
.use_spec_collector? is just an intermediate thing - it allowed me to test out the new collector code alongside the old collection code - that way I didn't need to chase the refactor all the way through the code. (I didn't want to do that if everyone thought it was a bad idea.)
If the general consensus is that it's a good idea, I'll finish it up, push the changes through the codebase and push it out to my fork at github
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Behaviour Driven Development for Ruby.
David Chelimsky