rspec users - Dec 2008 - Any plans for Before-feature or Before-all steps in Cucumber?

Hi

The code I''m working on now is a server daemon that talks to Twitter,  
an RSS feed, and some web pages.  I''ve got mock implementations of  
Twitter and the web stuff, which I start and stop with  
daemon_controller[1].  I do all the setup in a Before block, but this  
makes the feature runs agonisingly slow due to the time waiting for  
everything to restart.  I''m now starting a Merb app which will rely on
the database created by the server daemon, so it''s going to get even  
slower.

Are there any plans to add BeforeStory or BeforeAll blocks to  
Cucumber?  With this I could start everything once and add reset code  
to each daemon.

Ashley

[1]
http://blog.phusion.nl/2008/08/25/daemon_controller-a-library-for-robust-daemon-management/

-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

Ashley Moran wrote:
> Hi
>
> The code I''m working on now is a server daemon that talks to
Twitter,
> an RSS feed, and some web pages.  I''ve got mock implementations of
> Twitter and the web stuff, which I start and stop with 
> daemon_controller[1].  I do all the setup in a Before block, 
All defined before blocks are run for each scenario so this would slow 
down every scenario.
> but this makes the feature runs agonisingly slow due to the time 
> waiting for everything to restart.  I''m now starting a Merb app
which
> will rely on the database created by the server daemon, so it''s
going
> to get even slower.
>
> Are there any plans to add BeforeStory or BeforeAll blocks to 
> Cucumber?  With this I could start everything once and add reset code 
> to each daemon.
>
> Ashley
>
> [1] 
>
http://blog.phusion.nl/2008/08/25/daemon_controller-a-library-for-robust-daemon-management/
>
>
BeforeAll (Before running any feature) is currently possible through 
putting something in your env.rb or really any ruby file that gets 
required. It will be run once (and before anything else).
I use this to manage ferret/selenium. The before/afters being used to 
tell the service to cleanup so we have clean environment for each test. 
Could you do the same?

And Afterall is possible through: at_exit

BeforeFeature sounds like it could be useful for preparing services for 
that specific feature and you don''t want them running for other 
features. I guess currently  the only way of achieving this is 
separating those features and running them in separate cucumber runs. 
This is what I have done with something similar, using --profile to run 
different sets of features. I prefer this (in my experience so far) as 
it allows me to re-use my rake tasks for setting things up and keeps 
that setup from adding noise to my test code. I appreciate with mock 
services your situation is slightly different.

--
Joseph Wilk
http://blog.josephwilk.net

On 2 Dec 2008, at 15:26, Joseph Wilk wrote:
> BeforeAll (Before running any feature) is currently possible through  
> putting something in your env.rb or really any ruby file that gets  
> required. It will be run once (and before anything else).
> I use this to manage ferret/selenium. The before/afters being used  
> to tell the service to cleanup so we have clean environment for each  
> test. Could you do the same?
>
> And Afterall is possible through: at_exit
Yeah, I''ve had to resort to doing this, which makes the end of my  
env.rb look like this:

   #######################
   # Start everything up #
   #######################

   require ''support/service_controllers''

   # Note this relies on this file being loaded only once!

   ServiceControllers.stop_all
   ServiceControllers.start_all

   at_exit do
     ServiceControllers.stop_all
   end

I don''t like this though, it''s asymmetric.

> BeforeFeature sounds like it could be useful for preparing services  
> for that specific feature and you don''t want them running for
other
> features. I guess currently  the only way of achieving this is  
> separating those features and running them in separate cucumber  
> runs. This is what I have done with something similar, using -- 
> profile to run different sets of features. I prefer this (in my  
> experience so far) as it allows me to re-use my rake tasks for  
> setting things up and keeps that setup from adding noise to my test  
> code. I appreciate with mock services your situation is slightly  
> different.
I see what you mean, but it''s always useful to run all the features in
one run.  ''rake features'' should be the unambiguous,
authoritative
decider of whether your code can go live (IMHO).

Ashley

-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

Ashley Moran wrote:
>
> On 2 Dec 2008, at 15:26, Joseph Wilk wrote:
>
>> BeforeAll (Before running any feature) is currently possible through 
>> putting something in your env.rb or really any ruby file that gets 
>> required. It will be run once (and before anything else).
>> I use this to manage ferret/selenium. The before/afters being used to 
>> tell the service to cleanup so we have clean environment for each 
>> test. Could you do the same?
>>
>> And Afterall is possible through: at_exit
>
> Yeah, I''ve had to resort to doing this, which makes the end of my 
> env.rb look like this:
>
>   #######################
>   # Start everything up #
>   #######################
>
>   require ''support/service_controllers''
>
>   # Note this relies on this file being loaded only once!
>
>   ServiceControllers.stop_all
>   ServiceControllers.start_all
>
>   at_exit do
>     ServiceControllers.stop_all
>   end
>
> I don''t like this though, it''s asymmetric.
>
>
>> BeforeFeature sounds like it could be useful for preparing services 
>> for that specific feature and you don''t want them running for
other
>> features. I guess currently  the only way of achieving this is 
>> separating those features and running them in separate cucumber runs. 
>> This is what I have done with something similar, using --profile to 
>> run different sets of features. I prefer this (in my experience so 
>> far) as it allows me to re-use my rake tasks for setting things up 
>> and keeps that setup from adding noise to my test code. I appreciate 
>> with mock services your situation is slightly different.
>
> I see what you mean, but it''s always useful to run all the
features in
> one run.  ''rake features'' should be the unambiguous,
authoritative
> decider of whether your code can go live (IMHO).
>
> Ashley
>
I agree with Ashley.  In the past I have done multiple profiles just as 
Joseph has suggested.  I have then modified my features task to serially 
run my different feature sets and profiles.  With that you do have one 
task you need to run.  However, it would still be very nice if these 
different profile types, even if not ran as the same process, could be 
grouped into a single report and given then appearance that it was one 
large process.  I understand the problems and difficulties of doing such 
a thing, but WDYT?  If we think there is enough value in such an 
aggregate feature set  runner/report and we can decide on the details 
then I would be willing to tackle it.

-Ben

On 3 Dec 2008, at 16:59, Ben Mabey wrote:
> I agree with Ashley.  In the past I have done multiple profiles just  
> as Joseph has suggested.  I have then modified my features task to  
> serially run my different feature sets and profiles.  With that you  
> do have one task you need to run.  However, it would still be very  
> nice if these different profile types, even if not ran as the same  
> process, could be grouped into a single report and given then  
> appearance that it was one large process.  I understand the problems  
> and difficulties of doing such a thing, but WDYT?  If we think there  
> is enough value in such an aggregate feature set  runner/report and  
> we can decide on the details then I would be willing to tackle it.


Sounds like there''s two issues here.  One is grouping features into  
run sets (eg fast-running, slow-running; needs an external service, is  
self-contained) the other is running features in a certain mode (eg  
against mock-services, against live services; using HTML interface,  
using XML interface).

One solution to the first problem could be tagging the features/ 
scenarios:

Feature: blah
   Groups: slow
   As a...

   Scenario: blah
     Groups: twitter web

Or something.  Maybe?

The second problem currently has to be handled as separate Cucumber  
rake tasks with different --require options to load different steps.   
I don''t have any multi-mode features though, so I haven''t had
to worry
about this yet.  I suspect the general problem (given all the  
potential dimensions you could create) is currently unspecified and  
the general solution is quite hard...

I still think having an authoritative ''rake features'' is
essential,
though.

Ashley

-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Wed, Dec 3, 2008 at 7:01 PM, Ashley Moran
<ashley.moran at patchspace.co.uk>wrote:
>
> On 3 Dec 2008, at 16:59, Ben Mabey wrote:
>
>  I agree with Ashley.  In the past I have done multiple profiles just as
>> Joseph has suggested.  I have then modified my features task to
serially run
>> my different feature sets and profiles.  With that you do have one task
you
>> need to run.  However, it would still be very nice if these different
>> profile types, even if not ran as the same process, could be grouped
into a
>> single report and given then appearance that it was one large process. 
I
>> understand the problems and difficulties of doing such a thing, but
WDYT?
>>  If we think there is enough value in such an aggregate feature set
>>  runner/report and we can decide on the details then I would be willing
to
>> tackle it.
>
>
I think a nice way to facilitate one report from multiple cucumber runs is
useful.

I''m currently resorting to ''cat''ing (yuck!) the
different Cucumber reports
to get one html report in the features rake task.

Currently when you pass ''--out file'' to Cucumber it truncates
the file. We
could have it open the file for appending. That sounds like a simple
solution to forming one report from multiple runs.

You would still get the (minor) problem I have when ''cat''ing
the files (HTML
reports with multiple html heads).
>given then appearance that it was one large process.
Where you thinking about giving the appearance of one process at the report
level or the rake level?


>>
>
>
> Sounds like there''s two issues here.  One is grouping features
into run
> sets (eg fast-running, slow-running; needs an external service, is
> self-contained) the other is running features in a certain mode (eg against
> mock-services, against live services; using HTML interface, using XML
> interface).
>
> One solution to the first problem could be tagging the features/scenarios:
>
> Feature: blah
>  Groups: slow
>  As a...
>
>  Scenario: blah
>    Groups: twitter web
>
> Or something.  Maybe?

We currently have an issue on tagging but it will have to wait until Aslak
has done his AST magic.

http://rspec.lighthouseapp.com/projects/16211/tickets/54-tagging-scenarios

--
Joseph Wilk
http://blog.josephwilk.net

>
>
> The second problem currently has to be handled as separate Cucumber rake
> tasks with different --require options to load different steps.  I
don''t
> have any multi-mode features though, so I haven''t had to worry
about this
> yet.  I suspect the general problem (given all the potential dimensions you
> could create) is currently unspecified and the general solution is quite
> hard...
>
> I still think having an authoritative ''rake features'' is
essential, though.
>


>
>
> Ashley
>
> --
> http://www.patchspace.co.uk/
> http://aviewfromafar.net/
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081204/79d313f1/attachment.html>

On Thu, Dec 4, 2008 at 10:40 AM, Joseph Wilk <josephwilk at
joesniff.co.uk>wrote:
> On Wed, Dec 3, 2008 at 7:01 PM, Ashley Moran <
> ashley.moran at patchspace.co.uk> wrote:
>
>>
>> On 3 Dec 2008, at 16:59, Ben Mabey wrote:
>>
>>  I agree with Ashley.  In the past I have done multiple profiles just
as
>>> Joseph has suggested.  I have then modified my features task to
serially run
>>> my different feature sets and profiles.  With that you do have one
task you
>>> need to run.  However, it would still be very nice if these
different
>>> profile types, even if not ran as the same process, could be
grouped into a
>>> single report and given then appearance that it was one large
process.  I
>>> understand the problems and difficulties of doing such a thing, but
WDYT?
>>>  If we think there is enough value in such an aggregate feature set
>>>  runner/report and we can decide on the details then I would be
willing to
>>> tackle it.
>>
>>
> I think a nice way to facilitate one report from multiple cucumber runs is
> useful.
>
I think the way to go is to have a YAML formatter that can spit out reports
as YAML. Then several YAML reports can be read in.

My plan with the AST work is that the AST itself stores the results, so it
can be serialised and deserialised. This will make concatenating several
reports much easier.

>
> I''m currently resorting to ''cat''ing (yuck!) the
different Cucumber reports
> to get one html report in the features rake task.
>
> Currently when you pass ''--out file'' to Cucumber it
truncates the file. We
> could have it open the file for appending. That sounds like a simple
> solution to forming one report from multiple runs.
>
> You would still get the (minor) problem I have when
''cat''ing the files
> (HTML reports with multiple html heads).
>
>
>
> >given then appearance that it was one large process.
>
> Where you thinking about giving the appearance of one process at the report
> level or the rake level?
>
>
>
>>>
>>
>>
>> Sounds like there''s two issues here.  One is grouping features
into run
>> sets (eg fast-running, slow-running; needs an external service, is
>> self-contained) the other is running features in a certain mode (eg
against
>> mock-services, against live services; using HTML interface, using XML
>> interface).
>>
>> One solution to the first problem could be tagging the
features/scenarios:
>>
>> Feature: blah
>>  Groups: slow
>>  As a...
>>
>>  Scenario: blah
>>    Groups: twitter web
>>
>> Or something.  Maybe?
>
>
> We currently have an issue on tagging but it will have to wait until Aslak
> has done his AST magic.
>
Just a heads up - planning to get started on this around Dec 15th.

>
> http://rspec.lighthouseapp.com/projects/16211/tickets/54-tagging-scenarios
>
> --
> Joseph Wilk
> http://blog.josephwilk.net
>
>
>>
>>
>> The second problem currently has to be handled as separate Cucumber
rake
>> tasks with different --require options to load different steps.  I
don''t
>> have any multi-mode features though, so I haven''t had to worry
about this
>> yet.  I suspect the general problem (given all the potential dimensions
you
>> could create) is currently unspecified and the general solution is
quite
>> hard...
>>
>> I still think having an authoritative ''rake features''
is essential,
>> though.
>>
>
>
>
>
>>
>>
>> Ashley
>>
>> --
>> http://www.patchspace.co.uk/
>> http://aviewfromafar.net/
>>
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081204/4b157f30/attachment-0001.html>

On 4 Dec 2008, at 10:04, aslak hellesoy wrote:
> > We currently have an issue on tagging but it will have to wait  
> until Aslak has done his AST magic.
>
> Just a heads up - planning to get started on this around Dec 15th.
Sounds intriguing... what does AST mean / stand for?

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

On Thu, Dec 4, 2008 at 12:01 PM, Matt Wynne <matt at mattwynne.net> wrote:
>
> On 4 Dec 2008, at 10:04, aslak hellesoy wrote:
>
>  > We currently have an issue on tagging but it will have to wait until
>> Aslak has done his AST magic.
>>
>> Just a heads up - planning to get started on this around Dec 15th.
>>
>
> Sounds intriguing... what does AST mean / stand for?
>
http://en.wikipedia.org/wiki/Abstract_syntax_tree

>
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20081204/57be8a88/attachment.html>

Matt Wynne wrote:
>
> On 4 Dec 2008, at 10:04, aslak hellesoy wrote:
>
>> > We currently have an issue on tagging but it will have to wait 
>> until Aslak has done his AST magic.
>>
>> Just a heads up - planning to get started on this around Dec 15th.
>
> Sounds intriguing... what does AST mean / stand for?
Abstract Syntax Tree
http://en.wikipedia.org/wiki/Abstract_syntax_tree

--
Joseph Wilk
http://blog.josephwilk.net
>
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

aslak hellesoy wrote:
>
>
> On Thu, Dec 4, 2008 at 10:40 AM, Joseph Wilk 
> <josephwilk at joesniff.co.uk <mailto:josephwilk at
joesniff.co.uk>> wrote:
>
>     On Wed, Dec 3, 2008 at 7:01 PM, Ashley Moran
>     <ashley.moran at patchspace.co.uk
>     <mailto:ashley.moran at patchspace.co.uk>> wrote:
>
>
>         On 3 Dec 2008, at 16:59, Ben Mabey wrote:
>
>             I agree with Ashley.  In the past I have done multiple
>             profiles just as Joseph has suggested.  I have then
>             modified my features task to serially run my different
>             feature sets and profiles.  With that you do have one task
>             you need to run.  However, it would still be very nice if
>             these different profile types, even if not ran as the same
>             process, could be grouped into a single report and given
>             then appearance that it was one large process.  I
>             understand the problems and difficulties of doing such a
>             thing, but WDYT?  If we think there is enough value in
>             such an aggregate feature set  runner/report and we can
>             decide on the details then I would be willing to tackle it.
>
>
>     I think a nice way to facilitate one report from multiple cucumber
>     runs is useful.
>
>
> I think the way to go is to have a YAML formatter that can spit out 
> reports as YAML. Then several YAML reports can be read in.
Yeah, that was actually exactly what I was thinking!
>
> My plan with the AST work is that the AST itself stores the results, 
> so it can be serialised and deserialised. This will make concatenating 
> several reports much easier.
Ahh, I see. So the report concatenatenater would just have to load up 
all of the serialised ASTs and send them to one formatter?  So, I''m 
guessing you want to wait on this until after the AST work is done...  
I''ll open up a ticket in lighthouse for this regardless.

-Ben
>  
>
>
>     I''m currently resorting to ''cat''ing (yuck!)
the different Cucumber
>     reports to get one html report in the features rake task.
>
>     Currently when you pass ''--out file'' to Cucumber it
truncates the
>     file. We could have it open the file for appending. That sounds
>     like a simple solution to forming one report from multiple runs.
>
>     You would still get the (minor) problem I have when
''cat''ing the
>     files (HTML reports with multiple html heads).
>      
>
>
>
>     >given then appearance that it was one large process.
>
>     Where you thinking about giving the appearance of one process at
>     the report level or the rake level?
>
>
>
>
>
>
>         Sounds like there''s two issues here.  One is grouping
features
>         into run sets (eg fast-running, slow-running; needs an
>         external service, is self-contained) the other is running
>         features in a certain mode (eg against mock-services, against
>         live services; using HTML interface, using XML interface).
>
>         One solution to the first problem could be tagging the
>         features/scenarios:
>
>         Feature: blah
>          Groups: slow
>          As a...
>
>          Scenario: blah
>            Groups: twitter web
>
>         Or something.  Maybe?
>
>
>     We currently have an issue on tagging but it will have to wait
>     until Aslak has done his AST magic.
>
>
> Just a heads up - planning to get started on this around Dec 15th.
>  
>
>
>    
http://rspec.lighthouseapp.com/projects/16211/tickets/54-tagging-scenarios
>
>
>
>     --
>     Joseph Wilk
>     http://blog.josephwilk.net
>      
>
>
>
>         The second problem currently has to be handled as separate
>         Cucumber rake tasks with different --require options to load
>         different steps.  I don''t have any multi-mode features
though,
>         so I haven''t had to worry about this yet.  I suspect the
>         general problem (given all the potential dimensions you could
>         create) is currently unspecified and the general solution is
>         quite hard...
>
>         I still think having an authoritative ''rake
features'' is
>         essential, though.
>
>
>
>      
>
>
>
>         Ashley
>
>         -- 
>         http://www.patchspace.co.uk/
>         http://aviewfromafar.net/
>
>
>
>         _______________________________________________
>         rspec-users mailing list
>         rspec-users at rubyforge.org <mailto:rspec-users at
rubyforge.org>
>         http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
>     _______________________________________________
>     rspec-users mailing list
>     rspec-users at rubyforge.org <mailto:rspec-users at
rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/rspec-users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

> aslak hellesoy wrote:
>>
>>
>> On Thu, Dec 4, 2008 at 10:40 AM, Joseph Wilk <josephwilk at
joesniff.co.uk
>>  <mailto:josephwilk at joesniff.co.uk>> wrote:
>>
>>    On Wed, Dec 3, 2008 at 7:01 PM, Ashley Moran
>>    <ashley.moran at patchspace.co.uk
>>    <mailto:ashley.moran at patchspace.co.uk>> wrote:
>>
>>
>>        On 3 Dec 2008, at 16:59, Ben Mabey wrote:
>>
>>            I agree with Ashley.  In the past I have done multiple
>>            profiles just as Joseph has suggested.  I have then
>>            modified my features task to serially run my different
>>            feature sets and profiles.  With that you do have one task
>>            you need to run.  However, it would still be very nice if
>>            these different profile types, even if not ran as the same
>>            process, could be grouped into a single report and given
>>            then appearance that it was one large process.  I
>>            understand the problems and difficulties of doing such a
>>            thing, but WDYT?  If we think there is enough value in
>>            such an aggregate feature set  runner/report and we can
>>            decide on the details then I would be willing to tackle  
>> it.
>>
>>
>>    I think a nice way to facilitate one report from multiple cucumber
>>    runs is useful.
>>
>>
>> I think the way to go is to have a YAML formatter that can spit out  
>> reports as YAML. Then several YAML reports can be read in.
>
> Yeah, that was actually exactly what I was thinking!
>>
>> My plan with the AST work is that the AST itself stores the  
>> results, so it can be serialised and deserialised. This will make  
>> concatenating several reports much easier.
>
> Ahh, I see. So the report concatenatenater would just have to load  
> up all of the serialised ASTs and send them to one formatter?  So,  
> I''m guessing you want to wait on this until after the AST work is
> done...  I''ll open up a ticket in lighthouse for this regardless.
>
Spot on
> -Ben
>
>>
>>
>>    I''m currently resorting to ''cat''ing
(yuck!) the different Cucumber
>>    reports to get one html report in the features rake task.
>>
>>    Currently when you pass ''--out file'' to Cucumber
it truncates the
>>    file. We could have it open the file for appending. That sounds
>>    like a simple solution to forming one report from multiple runs.
>>
>>    You would still get the (minor) problem I have when
''cat''ing the
>>    files (HTML reports with multiple html heads).
>>
>>
>>
>>    >given then appearance that it was one large process.
>>
>>    Where you thinking about giving the appearance of one process at
>>    the report level or the rake level?
>>
>>
>>
>>
>>
>>
>>        Sounds like there''s two issues here.  One is grouping
features
>>        into run sets (eg fast-running, slow-running; needs an
>>        external service, is self-contained) the other is running
>>        features in a certain mode (eg against mock-services, against
>>        live services; using HTML interface, using XML interface).
>>
>>        One solution to the first problem could be tagging the
>>        features/scenarios:
>>
>>        Feature: blah
>>         Groups: slow
>>         As a...
>>
>>         Scenario: blah
>>           Groups: twitter web
>>
>>        Or something.  Maybe?
>>
>>
>>    We currently have an issue on tagging but it will have to wait
>>    until Aslak has done his AST magic.
>>
>>
>> Just a heads up - planning to get started on this around Dec 15th.
>>
>>
>>   
http://rspec.lighthouseapp.com/projects/16211/tickets/54-tagging-scenarios
>>
>>
>>
>>    --
>>    Joseph Wilk
>>    http://blog.josephwilk.net
>>
>>
>>
>>        The second problem currently has to be handled as separate
>>        Cucumber rake tasks with different --require options to load
>>        different steps.  I don''t have any multi-mode features
though,
>>        so I haven''t had to worry about this yet.  I suspect
the
>>        general problem (given all the potential dimensions you could
>>        create) is currently unspecified and the general solution is
>>        quite hard...
>>
>>        I still think having an authoritative ''rake
features'' is
>>        essential, though.
>>
>>
>>
>>
>>
>>
>>        Ashley
>>
>>        --         http://www.patchspace.co.uk/
>>        http://aviewfromafar.net/
>>
>>
>>
>>        _______________________________________________
>>        rspec-users mailing list
>>        rspec-users at rubyforge.org <mailto:rspec-users at
rubyforge.org>
>>        http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
>>
>>    _______________________________________________
>>    rspec-users mailing list
>>    rspec-users at rubyforge.org <mailto:rspec-users at
rubyforge.org>
>>    http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
>> --- 
>> ---------------------------------------------------------------------
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users