[rspec-devel] running only a select group of specs

Ben Mabey ben at benmabey.com
Wed Aug 20 22:35:36 EDT 2008


Zach Dennis wrote:
> On Tue, Aug 19, 2008 at 10:15 PM, Ben Mabey <ben at benmabey.com> wrote:
>   
>> Pat Maddox wrote:
>>     
>>> On Tue, Aug 19, 2008 at 8:38 PM, Ben Mabey <ben at benmabey.com> wrote:
>>>
>>>       
>>>> I know the easy thing would be to just create separate unit and
>>>> functional directories.. but that is something that I would like to
>>>> avoid.  Besides, that is easy and I like pain. :)
>>>>
>>>>         
>>> Why do you want to avoid that?  I think it's superior from an
>>> organizational standpoint, and doesn't require screwing with the
>>> runner.
>>>
>>> Pat
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>>       
>> I actually keep going back and forth on this.  I like having all of my
>> specs for a given object in the same file... When I'm specing out some
>> behavior and I realize that I really need to use the DB I like being
>> able to just declare it inline and not have to cut my spec and paste it
>> into another file in another dir.  Make sense?  Also, I think reading
>> the specs that way is less confusing...
>>
>>     
>
> I agree with Ben. Different directories works, but it definitely isn't
> my preferred route if there is way to cleanly and simply keep all
> examples for a particular object together. I like cohesiveness in my
> specs, and spreading examples out across separate files (and
> directories) for one object seems to decrease some amount of value. I
> think we can do better. A suggestion OTOMH is:
>
>   describe SomeModel, :use_db => true do
>   end
>
>   describe SomeModel, :use_db => false do
>   end
>
> And pick false as the default if :use_db isn't supplied. This kind of
> configurable capabilities can apply to more than just the database as
> well. I'd envision a config could look like:
>
> Spec::Runner.configure do |config|
>    config.use_db do |val|
>        unless val
>             # do everything to disallow database access
>        end
>    end
>
>    config.use_userdefined_thingy do |val|
>        unless val
>           # do everything to disallow user defined thingy
>        end
>    end
> end
>   

When would your config block be ran?  Before or after example groups? 
As I currently have it implemented I can create before and after blocks
on the config like so:

config.before(:all) do
    if example_group_options[:use_db]
     ActiveRecord::Base.establish_connection(:test)
    end
  end

  config.after(:all) do
   if example_group_options[:use_db]
     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
   end
  end

So perhaps a mixture of the two used like so would be ideal:

config.before(:all, :use_db => true) do
     ActiveRecord::Base.establish_connection(:test)
  end

  config.after(:all, :use_db => true) do
     ActiveRecord::Base.establish_connection(:adapter => :nulldb)
  end

The before and after blocks would essentially do pattern matching on the
example groups.  Meaning, they would only be executed if the example
group's options matched what is defined on config.  This is no different
from how you can already specify which example group types should use
certain before and after blocks.

Going back to my original question though.. with something like above in
place could you leverage the same pattern matching functionality in the
runner?
Well.. I'm sure you could, but as Pat said, is the value gained really
worth screwing with the runner?

OTOMH, specifying which example groups to be ran could perhaps be
defined in a rake task like so:

Spec::Rake::SpecTask.new(:db_specs) do |t|
  t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
  t.spec_files = FileList['spec/**/*_spec.rb']
  t.example_group_options = {:use_db => true}
end

This could allow a user to organize there specs how ever they like on
the filesystem and then rely on this tagging mechanism to run only
certain specs at certain times...

WDYT?

-Ben


More information about the rspec-devel mailing list