[rspec-devel] rspec_options / Spec::Story::Runner.run_options
Matt Patterson
matt-lists at reprocessed.org
Tue Apr 29 08:52:18 EDT 2008
I've done some work around refactoring and reworking the rspec_options
mechanism, for http://rspec.lighthouseapp.com/projects/5645/tickets/373-spec-story-runner-run_options-and-rspec_options-code-duplication-and-problems
. I thought it might be worth talking through what I've done and
why...
I was originally looking to try and figure out how to solve the
problem of Spec::Story::Runner.run_options getting nothing from ARGV
if you required 'spec/rails/story_adapter'. The problem was easy to
solve - just comment out the body of run_options and, basically, make
it delegate to rspec_options. Unfortunately, that caused lots of spec
failures that I couldn't wrap my head around...
Anyway, my observation was that things were hard to understand because
of the rspec_options juggling you needed to do to spec rspec...
I thought I'd have a look at finding a way to attack some of that, and
the ticket above, and the commit at http://github.com/fidothe/rspec/commit/71b03ed9dd9aa07aba24a94ee495d0adc00cdb3c
is my attempt at that.
My first thought was that rspec_options performed two main, and
distinct, tasks - collecting example groups to be run, and parsing the
options given so the examples can be run.
Collecting example groups is essentially done as a side effect when
classes containing examples are defined. As far as I could tell,
splitting out spec collection would be enough to stop rspec_options
getting called during the intial "require 'spec'" stage, and that
seemed like a win too.
My next thought was that it would be great if the monkeying you need
to do in order to spec out rspec itself could be made simpler and more
explicit.
I hope that what I've strikes people as a step towards that - I think
it's got potential.
I introduced Spec::Collector, the class, and Spec.collector, the
global accessor, in order to allow spec collection to be split out.
Using Spec.collector makes it really easy to stub out the collector
for specs involving it - like a lot of the example_group_methods
specs. I added a chunk of rewritten specs in spec/spec/example/
example_group_methods_spec.rb which demonstrate that. The before and
after :all blocks are there to allow side-by-side testing with the
existing rspec_options based stuff (as are the conditionals in the
code itself). I think that the resulting specs are a lot clearer - all
the monkeying is much more explicit, a lot of which is because of
being able to use mocks and stubs easily (I assume you could mock or
stub rspec_options, but you'd have to do something like rely on self-
as-implicit-receiver)
The same approach could easily be applied to rspec_options itself.
Any thoughts?
Matt
--
Matt Patterson | Design & Code
<matt at reprocessed org> | http://www.reprocessed.org/
More information about the rspec-devel
mailing list