[rspec-devel] rspec extensions

Brian Takita brian.takita at gmail.com
Thu Sep 20 01:01:11 EDT 2007


On 9/15/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> 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.
Right now, behaviour_type (probably should be renamed to example_type
or example_type) sets the superclass of the Example. I don't see how
multiple tags can be defined with behaviour_type's current
implementation.

Perhaps behaviour_type can include modules?
>
> Aslak
>
> 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
> > involved.).
> >
> > ----
> >
> > 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
> > rspec.
> > > 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
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>


More information about the rspec-devel mailing list