[rspec-devel] [Proposed Refactoring] - Current ExampleSpace class subclasses Test::Unit::TestCase

Dan North dan at tastapod.com
Wed Aug 22 13:40:29 EDT 2007


Hi Aslak.

aslak hellesoy wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>   
>> This is a way to utilize Test::Unit in rspec.
>>
>> There are a number of BDD frameworks that utilize Test::Unit to create
>> a simple implementation.
>>
>> This could also be a first step to using Test::Unit's runner.
>>     
A similar conversation happened in the early days of jbehave about 
whether to use junit's runner. We decided to go with our own runner 
(like rspec did) because we wanted it to do other stuff (mostly 
lifecycle callbacks).
> Using Test::Unit's runner might be compelling, but I don't know how
> easy it will be to make it behave like today's RSpec. We have a lot of
> extra command line options, different output and so on. I'm not sure
> what it takes to make it happen.
>   
I don't think it would be too difficult to write an adapter to run under 
test::unit. Right now, the describe method captures a block of code - 
the description (aka context) - and the it method captures another block 
of code - the example. You can replace these methods as follows:

- describe Sheep dynamically creates a class called SheepTest that 
extends a subclass of TestCase, then it executes its block to gather 
examples, by using a modified it() method as follows:
- it "should baa" dynamically creates a method in SheepTest called 
test_should_baa that looks like this:
cls.define_method :test_should_baa do
    begin
       alert_listeners(:starting)
       run_describe_block_with_it_method_disabled # so helper methods 
are defined
       run_the_actual_example_block
       alert_listeners(:succeeded)
    rescue
       alert_listeners(:failed)
       raise
    end
end

- Any before(:each) or after(:each) blocks get added to lists inside 
SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down methods.
- before :all and after :all would be more tricky, but they are 
discouraged anyway.

All this would allow test::unit to find the adapted test case in 
ObjectSpace with a bunch of test methods that it would run as normal. I 
wrote a hack like this a while back so that I could have test methods 
that started with "should_" instead of "test_" and it worked pretty 
well. (Then I deleted it all - d'oh!)

You can invoke the suite using testrb --options-to-test-unit -- 
--options-to-rspec-after-double-dash

Most of the rspec command line options are about attaching different 
listeners around the behaviour invocation, so this would still work 
using a template test method.

No doubt there are edge cases, but this would get us started.

> What would be the main benefit for users? And for us?
>   
Tools. Right now I can run a test::unit suite in eclipse using a 
short-cut and get a nice red/green tree of tests that I can drill into, 
right-click and re-run any test, etc. In contrast I can run my rspec 
suite as a "ruby application" and see rows of dots.

Any effort that goes into making test::unit easier to use (say in rake 
or buildr) is immediately useful to rspec.

Cheers,
Dan




More information about the rspec-devel mailing list