[rspec-devel] rspec extensions
nick at pivotalsf.com
Sat Sep 15 14:20:02 EDT 2007
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-devel