[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