[rspec-devel] rspec extensions
aslak.hellesoy at gmail.com
Sat Sep 15 17:31:36 EDT 2007
I agree that this is a compelling feature, especially for large suites
of slow specs. Java's TestNG has this feature already.
We alreadt have a mechanism for "tagging" behaviours using
:behaviour_type, and I think we should use the existing mechanism. We
can rename it if need be - TestNG calls it group, but :tag or :tags is
fine too - I like that.
On 9/15/07, Nick Kallen <nick at pivotalsf.com> wrote:
> I can wait for the next release... When is it coming out? Perhaps we can
> convince Rob to let you and I pair on this. I'd like to be involved so I get
> some credit... ;)
> I have a couple use cases for tags, but in general the idea is to be able to
> run a smaller subset of tests so that you can check in more frequently.
> Obvious partitions include "fast" and "slow" (or as I prefer, "smoke" and
> "regression", which is not equivalent to "fast" and "slow"). Less obvious,
> but equally valuable, is to partition your test suites by functionality
> "verticals". For example, being able to run all accounting-related tests, or
> user-related tests, or asset-related tests, etc. Often these "verticals" cut
> across files and describe-blocks (at least, in rails, they cut across model,
> view, helper, and controller specs--but typically also multiple models are
> I've also been wondering how hard it would be to make the test runner into a
> scheduler. What if we could have four databases:
> application_test_1, application_test_2, etc.
> And have the test runner create 4 Rails environments on the fly and run
> tests in parallel across them. Some thoughtworks people have been
> parallelizing tests by running them all in individual transactions. The
> problem here is that fixtures aren't inserted as transactions so it excludes
> fixture-based tests. You can load the fixtures in transactions but since
> Transactions involve full-table locks, in effect the tests don't run in
> parallel. The "scheduling" approach seems to me more sensible. The only
> issue is migrating 4 sep databases which can probably be done very rapidly
> by means of schema.rb or a dump from one db to the next.
> On 9/15/07, Brian Takita <brian.takita at gmail.com> wrote:
> > On 9/12/07, Nick Kallen <nick at pivotalsf.com > wrote:
> > > i know you're on vacation but i'd bet you're checking your email:
> > Not that often. Ive been able to stay away for the most part :)
> > I'm ccing the rspec developer list for more ideas.
> > >
> > > i want to add an extension to RSpec. I'd like to be able to "tag" it and
> > > describe statements. For example:
> > >
> > > it "should ensure that my checkbook is balanced", :tags => [:smoke,
> > > :accounting] do
> > > end
> > >
> > > describe Checkbook, "foobar", :tags => [:fast, :accounting] do
> > > end
> > >
> > > (syntax TBD)
> > >
> > > I then want a rake task like:
> > >
> > > rake spec TAGS=(fast and accounting)
> > > rake spec TAGS=(regression or user)
> > >
> > > ---
> > >
> > > How hard would it be to do something like this? Does Rspec have a plugin
> > > framework?
> > Thats really interesting. There has been talk about adding tagging to
> > I really like it. This feature would be particularly useful for mature
> > projects where the precheckin tests are reducing productivity by being
> > slow. Nick, do you have some other use cases in mind?
> > rspec is a moving target. The internals in svn trunk are significantly
> > different from the current release (1.0.8).
> > I think such a tagging feature would be useful in rspec core. To add
> > it to rspec core (trunk), I think the following objects need to be
> > touched (without seeing the code):
> > * Tagging object(s)
> > * Example.suite
> > * ExampleApi (describe, it, and tags methods)
> > * ExampleDefinition (tags method)
> > * Options (For non-rake command line arguments)
> > * OptionParser (For non-rake command line arguments)
> > * maybe SpecTask
> > I suspect, in your case, you only care about rake, so you would not
> > need to care about Options and OptionParser.
> > Is this something that you would like to do really soon or can you
> > wait for the next release?
> > If you want to do it before the next release, the touch points will be
> > a little different.
> > The closest thing to a plugin architure is the a configuration object.
> > The tags feature seems like it should be implementable by a plugin but
> > now requires vertical changes (across several objects). It seems there
> > is some work needed there.
> > Brian
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel