rspec users - Aug 2008 - Documentation for Plain-Text Stories

Can I help the project by writing some docs about the plain-text  
story runner for the rspec.info website? It would surely help me to  
get it wired in my own mind if I have to write it up for the world.

Would this be helpful / appreciated?

What format would you want them in?

cheers,
Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080812/323afe52/attachment.html>

Matt,

Do you want to pair on this? I am writing some stuff for the Watir
site. I sent you some example code as well.

Aidy

On 12/08/2008, Matt Wynne <matt at mattwynne.net>
wrote:
>
> Can I help the project by writing some docs about the plain-text story
> runner for the rspec.info website? It would surely help me to get it wired
> in my own mind if I have to write it up for the world.
>
> Would this be helpful / appreciated?
>
> What format would you want them in?
>
>
> cheers,
> Matt
>
> _______________________________________________
>  rspec-users mailing list
>  rspec-users at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-users
>

That would be cool, though I think it might be hard to compete with  
something like this:
http://www.joesniff.co.uk/ruby/telling-a-good-story-rspec-stories- 
from-the-trenches.html

cheers,
Matt
----
http://blog.mattwynne.net


On 18 Aug 2008, at 08:34, aidy lewis wrote:
> Matt,
>
> Do you want to pair on this? I am writing some stuff for the Watir
> site. I sent you some example code as well.
>
> Aidy
>
> On 12/08/2008, Matt Wynne <matt at mattwynne.net> wrote:
>>
>> Can I help the project by writing some docs about the plain-text  
>> story
>> runner for the rspec.info website? It would surely help me to get  
>> it wired
>> in my own mind if I have to write it up for the world.
>>
>> Would this be helpful / appreciated?
>>
>> What format would you want them in?
>>
>>
>> cheers,
>> Matt
>>
>> _______________________________________________
>>  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

Hello,

I left out of my Rspec story post Selenium/Webrat integration. I thought
I would release that as a separate post.

While I can write about how I deal with Selenium/Webrat in Rspec I''m
yet
to use Watir. So I think putting something together on Watir integration
as Matt suggested would be really helpful to the community.

--
Joseph Wilk
http://www.joesniff.co.uk



On Mon, 2008-08-18 at 08:43 +0100, Matt Wynne wrote:
> That would be cool, though I think it might be hard to compete with  
> something like this:
> http://www.joesniff.co.uk/ruby/telling-a-good-story-rspec-stories- 
> from-the-trenches.html
> 
> cheers,
> Matt
> ----
> http://blog.mattwynne.net
> 
> 
> On 18 Aug 2008, at 08:34, aidy lewis wrote:
> 
> > Matt,
> >
> > Do you want to pair on this? I am writing some stuff for the Watir
> > site. I sent you some example code as well.
> >
> > Aidy
> >
> > On 12/08/2008, Matt Wynne <matt at mattwynne.net> wrote:
> >>
> >> Can I help the project by writing some docs about the plain-text  
> >> story
> >> runner for the rspec.info website? It would surely help me to get
> >> it wired
> >> in my own mind if I have to write it up for the world.
> >>
> >> Would this be helpful / appreciated?
> >>
> >> What format would you want them in?
> >>
> >>
> >> cheers,
> >> Matt
> >>
> >> _______________________________________________
> >>  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
> 
> _______________________________________________
> 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/20080818/c33b76e4/attachment.html>

On Tue, Aug 12, 2008 at 6:45 PM, Matt Wynne <matt at mattwynne.net>
wrote:
> Can I help the project by writing some docs about the plain-text story
> runner for the rspec.info website? It would surely help me to get it wired
> in my own mind if I have to write it up for the world.
> Would this be helpful / appreciated?
> What format would you want them in?
>
The RSpec Story runner is likely to be deprecated in favour of the new
feature runner (temporarily called Cucumber).
http://www.nabble.com/-ANN--Cucumber-td18876816.html

The RSpec Story runner will continue to exist for a while, I just
wanted to let you know that future development and documentation
efforts will be focused on Cucumber. Cucumber also has some
documentation and examples on Github, more specifically:

* How to use without Rails
* How to use with Rails+Webrat
* How to use with Watir

Please let me know if you''d like to help out documenting Cucumber. One
thing that is missing is a migration guide from RSpec Story runner.

Cheers,
Aslak
> cheers,
> Matt
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

>
> The RSpec Story runner is likely to be deprecated in favour of the new
> feature runner (temporarily called Cucumber).
> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>
And this is going to be distributed as a separate plug-in from RSpec?

On Mon, Aug 18, 2008 at 1:06 PM, Matt Wynne <matt at mattwynne.net>
wrote:
>>
>> The RSpec Story runner is likely to be deprecated in favour of the new
>> feature runner (temporarily called Cucumber).
>> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>>
>
> And this is going to be distributed as a separate plug-in from RSpec?
For the time being it is in a separate Git repo. It can be built as a
gem and installed as a gem. Rails users can also install it as a
plugin.

We haven''t decided yet whether it will continue to be in a separate
repo or added to the RSpec codebase. From a maintenance perspective I
think it''s easier to keep things separate and small than lump
everything together in a big codebase. From a Rails user perspective
it means you need to install 3 plugins instead of 2
(RSpec+RSpec-Rails+Cucumber).

What do you think is the best thing to do?

Aslak
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

I think it''s better to make them separate. Conceptually, the story  
runner slightly confuses the identity of what RSpec is - is it for  
specifying behaviour of individual classes (a la TDD) or is it for  
specifying the behaviour of the whole system? I think the describe /  
it / should thing is powerful enough in its own right as a way to  
express behaviour of individual classes. Coming from writing XUnit  
tests I absolutely love it - it''s such a natural way to describe the  
desired behaviour.

Presumably you might also end up needing something like a Cucumber- 
Rails plugin, or are you envisaging tying Cucumber to rails?

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.

On 18 Aug 2008, at 12:11, aslak hellesoy wrote:
> On Mon, Aug 18, 2008 at 1:06 PM, Matt Wynne <matt at mattwynne.net>  
> wrote:
>>>
>>> The RSpec Story runner is likely to be deprecated in favour of  
>>> the new
>>> feature runner (temporarily called Cucumber).
>>> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>>>
>>
>> And this is going to be distributed as a separate plug-in from RSpec?
>
> For the time being it is in a separate Git repo. It can be built as a
> gem and installed as a gem. Rails users can also install it as a
> plugin.
>
> We haven''t decided yet whether it will continue to be in a
separate
> repo or added to the RSpec codebase. From a maintenance perspective I
> think it''s easier to keep things separate and small than lump
> everything together in a big codebase. From a Rails user perspective
> it means you need to install 3 plugins instead of 2
> (RSpec+RSpec-Rails+Cucumber).
>
> What do you think is the best thing to do?
>
> Aslak
>
>> _______________________________________________
>> 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

On Mon, Aug 18, 2008 at 1:24 PM, Matt Wynne <matt at mattwynne.net>
wrote:
> I think it''s better to make them separate. Conceptually, the story
runner
> slightly confuses the identity of what RSpec is - is it for specifying
> behaviour of individual classes (a la TDD) or is it for specifying the
> behaviour of the whole system? I think the describe / it / should thing is
> powerful enough in its own right as a way to express behaviour of
individual
> classes. Coming from writing XUnit tests I absolutely love it -
it''s such a
> natural way to describe the desired behaviour.
>
> Presumably you might also end up needing something like a Cucumber-Rails
> plugin, or are you envisaging tying Cucumber to rails?
>
Cucumber is not tied to Rails at all - it is  designed to work with
any Ruby code (including JRuby and hopefully soon other Rubies).
However, Cucumber comes with a couple of hooks for Rails, which in
turn have a dependency on RSpec-Rails:

http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/rails/rspec.rb
http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/rails/world.rb

When you use Cucumber''s generators to set it up in a Rails project (as
described in the README), these hooks are enabled by default.

Aslak
> cheers,
> Matt
> ----
> http://blog.mattwynne.net
> http://songkick.com
>
> In case you wondered: The opinions expressed in this email are my own and
do
> not necessarily reflect the views of any former, current or future
employers
> of mine.
>
> On 18 Aug 2008, at 12:11, aslak hellesoy wrote:
>
>> On Mon, Aug 18, 2008 at 1:06 PM, Matt Wynne <matt at
mattwynne.net> wrote:
>>>>
>>>> The RSpec Story runner is likely to be deprecated in favour of
the new
>>>> feature runner (temporarily called Cucumber).
>>>> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>>>>
>>>
>>> And this is going to be distributed as a separate plug-in from
RSpec?
>>
>> For the time being it is in a separate Git repo. It can be built as a
>> gem and installed as a gem. Rails users can also install it as a
>> plugin.
>>
>> We haven''t decided yet whether it will continue to be in a
separate
>> repo or added to the RSpec codebase. From a maintenance perspective I
>> think it''s easier to keep things separate and small than lump
>> everything together in a big codebase. From a Rails user perspective
>> it means you need to install 3 plugins instead of 2
>> (RSpec+RSpec-Rails+Cucumber).
>>
>> What do you think is the best thing to do?
>>
>> Aslak
>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Hi Aslak


2008/8/18 aslak hellesoy <aslak.hellesoy at
gmail.com>:
> * How to use with Watir
gem sources --add http://gems.github.com/
gem install aslakhellesoy-cucumber

I am unable top find the Watir and Cucumber example

Aidy

On Mon, Aug 18, 2008 at 2:29 PM, aidy lewis <aidy.lewis at googlemail.com>
wrote:
> Hi Aslak
>
>
> 2008/8/18 aslak hellesoy <aslak.hellesoy at gmail.com>:
>> * How to use with Watir
>
> gem sources --add http://gems.github.com/
> gem install aslakhellesoy-cucumber
>
> I am unable top find the Watir and Cucumber example
>
I may have forgotten to include the examples in the gem. Until I get
it fixed and push a new gem - try to get the source from Git instead:

git clone git://github.com/aslakhellesoy/cucumber.git

Look in the examples/watir directory:
http://github.com/aslakhellesoy/cucumber/tree/master/examples/watir

Aslak
> Aidy
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Aslak
> Look in the examples/watir directory:
> http://github.com/aslakhellesoy/cucumber/tree/master/examples/watir
>
> Aslak
>
OK. Can I expand on this for your example?

Aidy

On Mon, Aug 18, 2008 at 3:02 PM, aidy lewis <aidy.lewis at googlemail.com>
wrote:
> Aslak
>
>> Look in the examples/watir directory:
>> http://github.com/aslakhellesoy/cucumber/tree/master/examples/watir
>>
>> Aslak
>>
> OK. Can I expand on this for your example?
>
What do you mean by expand?

Aslak
> Aidy
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Aslak

2008/8/18 aslak hellesoy <aslak.hellesoy at gmail.com>:
>
> What do you mean by expand?
>
> Aslak
>
I was going to give a more detailed example...

Aidy

On Mon, Aug 18, 2008 at 3:31 PM, aidy lewis <aidy.lewis at googlemail.com>
wrote:
> Aslak
>
> 2008/8/18 aslak hellesoy <aslak.hellesoy at gmail.com>:
>
>>
>> What do you mean by expand?
>>
>> Aslak
>>
>
> I was going to give a more detailed example...
>
That would be awesome. If you''re familiar with Git you can clone my
Cucumber and commit your changes to your clone. If not I''ll accept a
patch. Just put it in RSpec''s Lighthouse and tag it with cucumber

Aslak
> Aidy
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Hi,
Bret Pettichord tells me yourself and him worked together on an
improvement to the watir example. Could you commit it and i will
expand on it and wrap it up into an AUT object model.
Aidy.

On 8/18/08, aslak hellesoy <aslak.hellesoy at gmail.com>
wrote:
> On Mon, Aug 18, 2008 at 3:31 PM, aidy lewis <aidy.lewis at
googlemail.com>
> wrote:
>> Aslak
>>
>> 2008/8/18 aslak hellesoy <aslak.hellesoy at gmail.com>:
>>
>>>
>>> What do you mean by expand?
>>>
>>> Aslak
>>>
>>
>> I was going to give a more detailed example...
>>
>
> That would be awesome. If you''re familiar with Git you can clone
my
> Cucumber and commit your changes to your clone. If not I''ll accept
a
> patch. Just put it in RSpec''s Lighthouse and tag it with cucumber
>
> Aslak
>
>> Aidy
>> _______________________________________________
>> 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
>
-- 
Sent from Google Mail for mobile | mobile.google.com

On Aug 18, 2008, at 8:57 PM, aidy lewis wrote:
> Hi,
> Bret Pettichord tells me yourself and him worked together on an
> improvement to the watir example. Could you commit it and i will
> expand on it and wrap it up into an AUT object model.
> Aidy.
>
Hi Aidy. So you and I have the same Bret number eh? ;-)

I committed it on Aug 6th, with Bret''s kudos and everything:

http://github.com/aslakhellesoy/cucumber/search?q=bret&choice=grep
(click on the "commit" link to see what we did and where the files
are)

Aslak

> On 8/18/08, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>> On Mon, Aug 18, 2008 at 3:31 PM, aidy lewis <aidy.lewis at
googlemail.com
>> >
>> wrote:
>>> Aslak
>>>
>>> 2008/8/18 aslak hellesoy <aslak.hellesoy at gmail.com>:
>>>
>>>>
>>>> What do you mean by expand?
>>>>
>>>> Aslak
>>>>
>>>
>>> I was going to give a more detailed example...
>>>
>>
>> That would be awesome. If you''re familiar with Git you can
clone my
>> Cucumber and commit your changes to your clone. If not I''ll
accept a
>> patch. Just put it in RSpec''s Lighthouse and tag it with
cucumber
>>
>> Aslak
>>
>>> Aidy
>>> _______________________________________________
>>> 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
>>
>
> -- 
> Sent from Google Mail for mobile | mobile.google.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

aslak hellesoy wrote:
> 
> The RSpec Story runner is likely to be deprecated in favour of the new
> feature runner (temporarily called Cucumber).
> http://www.nabble.com/-ANN--Cucumber-td18876816.html
This is REALLY bad news!! I asked this question a while back, I have a LOT of
code using story
runner, I have committed to do all my integration testing via stories, although
the ruby style ones
not the plain text ones.

To hear that they will be deprecated is not good news, and will cause me a lot
of grief if I have to
rewrite several thousand lines of code, or I simply won''t be able to
use the latest RSpec.

I suggest that cucumber stay separate, and RSpec keep the story runner, either
as core or as an add on.

Deprecating something that is being used extensively will not make your users
happy.


-- 
Jim Morris, http://blog.wolfman.com

On Mon, Aug 18, 2008 at 2:46 PM, Jim Morris <ml at e4net.com>
wrote:
> aslak hellesoy wrote:
>
>>
>> The RSpec Story runner is likely to be deprecated in favour of the new
>> feature runner (temporarily called Cucumber).
>> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>
> This is REALLY bad news!! I asked this question a while back, I have a LOT
> of code using story runner, I have committed to do all my integration
> testing via stories, although the ruby style ones not the plain text ones.
>
> To hear that they will be deprecated is not good news, and will cause me a
> lot of grief if I have to rewrite several thousand lines of code, or I
> simply won''t be able to use the latest RSpec.
>
> I suggest that cucumber stay separate, and RSpec keep the story runner,
> either as core or as an add on.
>
> Deprecating something that is being used extensively will not make your
> users happy.
Unless of course they are provided an easy transition to a new tool
that''s much better :)
>
>
> --
> Jim Morris, http://blog.wolfman.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Mon, Aug 18, 2008 at 9:46 PM, Jim Morris <ml at e4net.com>
wrote:
> aslak hellesoy wrote:
>
>>
>> The RSpec Story runner is likely to be deprecated in favour of the new
>> feature runner (temporarily called Cucumber).
>> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>
> This is REALLY bad news!! I asked this question a while back, I have a LOT
> of code using story runner, I have committed to do all my integration
> testing via stories, although the ruby style ones not the plain text ones.
>
Calm down.

You are not the only one who has invested in stories - plain text or
Ruby. I am also involved in a couple of projects that has lot of RSpec
stories. This is actually the main reason I wrote Cucumber - I got
tired of many of the shortcomings that I have outlined at the bottom
of Cucumber''s README.

Nobody is going to delete the RSpec story runner. (Some said taking
something off the Internet is like taking pee out of a swimming pool).
For what I know it will still be available for download 20 years from
now. I am only making people aware of Cucumber and encouraging them to
invest in improving it rather than the old one.

I realise that in order for people to be able to make the switch
painlessly, there needs to be good documentation - both about how to
migrate old style stories and also general documentation about how to
use Cucumber. I intend to provide most of this, and welcome others to
join in. The code also needs to be more or less of a drop-in
replacement, and one of my primary goals going forward is to make it
exactly that.

FYI - Cucumber already supports pure Ruby style. It''s not 100% similar
to RSpec Story runner in pure Ruby mode, but close.
http://github.com/aslakhellesoy/cucumber/tree/master/examples/calculator_ruby_features

I''m inviting you to provide some constructive feedback about how we
could improve it to make the transition easier for people like
yourself.

A natural part of software evolution is that every now and then a
tool, library or program gets replaced by something better. While it''s
certainly possible to maintain two different products, it takes a lot
more time. Time that I don''t have. Am I to understand from your email
that you''re stepping up and offering to help maintain and govern the
future of the story runner?
> To hear that they will be deprecated is not good news, and will cause me a
> lot of grief if I have to rewrite several thousand lines of code, or I
> simply won''t be able to use the latest RSpec.
>
What exactly is your understanding of deprecation and how have you
concluded that you will have rewrite several thousands of LOC?
> I suggest that cucumber stay separate, and RSpec keep the story runner,
> either as core or as an add on.
>
> Deprecating something that is being used extensively will not make your
> users happy.
>
What David said.

Aslak
>
> --
> Jim Morris, http://blog.wolfman.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

aslak hellesoy wrote:
> I''m inviting you to provide some constructive feedback about how
we
> could improve it to make the transition easier for people like
> yourself.
I''ll give it a try, I''ll port some of my stories to cucumber
and see how it goes.
> 
> A natural part of software evolution is that every now and then a
> tool, library or program gets replaced by something better. While
it''s
> certainly possible to maintain two different products, it takes a lot
> more time. Time that I don''t have. Am I to understand from your
email
> that you''re stepping up and offering to help maintain and govern
the
> future of the story runner?
True, but Story runner was only released in the last version of RSpec so it
isn''t exactly old.
Depending on how hard it is to port from story runner to cucumber, I''ll
have to make a decision to
either port, or maintain the old code, it is a trade off of time. Right now I
have my entire
integration testing suite written using story runner.

On an initial look at cucumber it looks like the steps remain pretty much the
same, although I see
you added Before and After, and I was using before story and after story
listeners for setup, not
sure what scope the Before and After have. I also use a before Scenario listener
to clear the
context before each scenario.
> 
> What exactly is your understanding of deprecation and how have you
> concluded that you will have rewrite several thousands of LOC?
What I have seen in the Ruby world (and Java) is that deprecation means the next
release prints some
warning that the feature is deprecated if you use it, then the following release
it is removed entirely.

I''ll site the Ruby Gem Sequel as an example of some recent
deprecations, that caused me to go
through many lines of code and update them as the feature I was using was
deprecated, and I
initially got a lot of warnings, then all my scripts stopped working after an
upgrade.

Maybe I won''t have to rewrite "thousands" of lines of code,
at least I hope not, if the steps remain
the same, I guess I''ll need to massage them and rewrite many of the
scenarios to fit the new format.

I have to say my reaction is due to the fact that tests are something you want
to write once and
forget, I don''t mind writing new tests using cucumber moving forward,
but to have to revisit old
tests is not a good use of my time. If you were to reword deprecation to frozen
I''d be a lot happier
:) then I can leave my old tests alone and use cucumber for new tests.



--
Jim Morris, http://blog.wolfman.com

On Aug 19, 2008, at 6:28 AM, Jim Morris wrote:
> aslak hellesoy wrote:
>
>> I''m inviting you to provide some constructive feedback about
how we
>> could improve it to make the transition easier for people like
>> yourself.
>
> I''ll give it a try, I''ll port some of my stories to
cucumber and see
> how it goes.
>
>> A natural part of software evolution is that every now and then a
>> tool, library or program gets replaced by something better. While  
>> it''s
>> certainly possible to maintain two different products, it takes a lot
>> more time. Time that I don''t have. Am I to understand from
your email
>> that you''re stepping up and offering to help maintain and
govern the
>> future of the story runner?
>
> True, but Story runner was only released in the last version of  
> RSpec so it isn''t exactly old.
It was introduced in version 1.1.0 - about 8 months ago. That''s not  
old I agree with you.
>
> Depending on how hard it is to port from story runner to cucumber,  
> I''ll have to make a decision to either port, or maintain the old  
> code, it is a trade off of time. Right now I have my entire  
> integration testing suite written using story runner.
>
I would recommend that you keep using the story runner until the  
effort required to switch is so small that you can do it in an hour or  
two.
> On an initial look at cucumber it looks like the steps remain pretty  
> much the same, although I see you added
They do remain pretty much the same, but I''m considering to move them  
from the toplevel scope and into classes (I prefer pure Ruby  
constructs instead of inventing our own cleverness).

class MySteps < Cucumber::Steps # Same as Story runnner steps_for(:my)
   Given /bla bla/ do
   end
end

> Before and After, and I was using before story and after story  
> listeners for setup, not sure what scope the Before and After have.  
> I also use a before Scenario listener to clear the context before  
> each scenario.
>
Right now the scope of Before/After is global - i.e. all Before and  
After blocks will run before and after each scenario. I have  
deliberately postponed adding scoping of this until I better  
understand how people want to define this scoping.

Here is one ideas:

class MySteps < Cucumber::Steps # Same as Story runnner steps_for(:my)
   Before do
     # This block will run before all scenarios that use steps from  
MySteps
     # Any scenarios not using any of these will not have this block run
   end

   Given /bla bla/ do
   end
end

I''m open to other ideas too.

In any case, a backwards compatible layer should be added so you can  
still use Scenario listeners if you wish.
>> What exactly is your understanding of deprecation and how have you
>> concluded that you will have rewrite several thousands of LOC?
>
> What I have seen in the Ruby world (and Java) is that deprecation  
> means the next release prints some warning that the feature is  
> deprecated if you use it, then the following release it is removed  
> entirely.
>
> I''ll site the Ruby Gem Sequel as an example of some recent  
> deprecations, that caused me to go through many lines of code and  
> update them as the feature I was using was deprecated, and I  
> initially got a lot of warnings, then all my scripts stopped working  
> after an upgrade.
>
Don''t worry. We''ll keep it around inside RSpec for a while
still. Only
when we are confident that migration to Cucumber is painless will we  
take it out. At that point it will probably just be moved to a  
separate Git repo so those who wish can maintain it as a separate  
project.
> Maybe I won''t have to rewrite "thousands" of lines of
code, at least
> I hope not, if the steps remain the same, I guess I''ll need to  
> massage them and rewrite many of the scenarios to fit the new format.
>
My goal is that you won''t have to change anything at all, except  
perhaps the parts that deal with running stories (you''ll get a Rake  
task and can delete your all.rb file). You shouldn''t have to change  
the story/step files.
> I have to say my reaction is due to the fact that tests are  
> something you want to write once and forget, I don''t mind writing
> new tests using cucumber moving forward, but to have to revisit old  
> tests is not a good use of my time. If you were to reword  
> deprecation to frozen I''d be a lot happier :) then I can leave my
> old tests alone and use cucumber for new tests.
>
Words are powerful aren''t they :-)

Frozen is probably a better word. No more significant development on it.

Thanks a lot for your feedback - looking forward to more concrete ones  
so I can make Cucumber better.

Aslak
>
>
> --
> Jim Morris, http://blog.wolfman.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

> What do you think is the best thing to do?
I would prefer to merge it into RSpec whenever it''s ready.  One of the
strong points about RSpec is that it''s a complete BDD toolkit: example
framework for developer testing, feature runner for customer test, and
the mock objects framework.  People can get started with one part of
the toolkit, and gradually use the other pieces as their wants and
needs develop.  I think it was a big win when RBehave merged into
RSpec.  If Cucumber represents significant improvements over the
current Story Runner, I''d like to see those improvements make it into
RSpec.

Pat

On 8/19/08, Pat Maddox <pergesu at gmail.com>
wrote:
> I would prefer to merge it into RSpec whenever it''s ready.
For whatever its worth I agree with Pat.  Most of the short-comings of
the existing story runner that Aslak describes in the Cucumber README
are things that we at weplay have had to hack together.  Having some
standardization for running a single scenario, or all scenarios, would
make developing tools on-top of the framework that much easier.

Josh

-- 
Josh Knowles
phone: 509-979-1593
email:  joshknowles at gmail.com
web:    http://joshknowles.com

Aslak Helles?y wrote:
> 
> Right now the scope of Before/After is global - i.e. all Before and 
> After blocks will run before and after each scenario. I have 
> deliberately postponed adding scoping of this until I better understand 
> how people want to define this scoping.
> 
> Here is one ideas:
> 
> class MySteps < Cucumber::Steps # Same as Story runnner steps_for(:my)
>   Before do
>     # This block will run before all scenarios that use steps from MySteps
>     # Any scenarios not using any of these will not have this block run
>   end
> 
>   Given /bla bla/ do
>   end
> end
> 
> I''m open to other ideas too.
I''d like to have a before story and after story as well as a before
scenario and after scenario.

Right now I do global setup for a story, and cleanup when the story is done. I
also do a setup
before each scenario as well.

It would be nice to have the ability to do both.

Thanks

-- 
Jim Morris, http://blog.wolfman.com

On Aug 20, 2008, at 1:04 AM, Pat Maddox wrote:
>> What do you think is the best thing to do?
>
> I would prefer to merge it into RSpec whenever it''s ready.  One of
the
> strong points about RSpec is that it''s a complete BDD toolkit:
example
> framework for developer testing, feature runner for customer test, and
> the mock objects framework.  People can get started with one part of
> the toolkit, and gradually use the other pieces as their wants and
I agree. These are the key success factors of Ruby on Rails.

-Which consists of 5 or so gems

Aslak
>
> needs develop.  I think it was a big win when RBehave merged into
> RSpec.  If Cucumber represents significant improvements over the
> current Story Runner, I''d like to see those improvements make it
into
> RSpec.
>
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Aug 20, 2008, at 7:04 AM, Jim Morris wrote:
> Aslak Helles?y wrote:
>
>> Right now the scope of Before/After is global - i.e. all Before and  
>> After blocks will run before and after each scenario. I have  
>> deliberately postponed adding scoping of this until I better  
>> understand how people want to define this scoping.
>> Here is one ideas:
>> class MySteps < Cucumber::Steps # Same as Story runnner  
>> steps_for(:my)
>>  Before do
>>    # This block will run before all scenarios that use steps from  
>> MySteps
>>    # Any scenarios not using any of these will not have this block  
>> run
>>  end
>>  Given /bla bla/ do
>>  end
>> end
>> I''m open to other ideas too.
>
> I''d like to have a before story and after story as well as a
before
> scenario and after scenario.
>
> Right now I do global setup for a story, and cleanup when the story  
> is done. I also do a setup before each scenario as well.
>
> It would be nice to have the ability to do both.
Can you give me a code example? (In Cucumber it''s Feature, not Story)

Aslak
>
>
> Thanks
>
> -- 
> Jim Morris, http://blog.wolfman.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Wed, Aug 20, 2008 at 8:32 AM, Jim Morris <ml at e4net.com>
wrote:
> Aslak Helles?y wrote:
>
>>>
>>> I''d like to have a before story and after story as well as
a before
>>> scenario and after scenario.
>>>
>>> Right now I do global setup for a story, and cleanup when the story
is
>>> done. I also do a setup before each scenario as well.
>>>
>>> It would be nice to have the ability to do both.
>>
>> Can you give me a code example? (In Cucumber it''s Feature, not
Story)
>>
>
> An example of how I would use it or an example of how to do it?
>
Of how you would use it. Assume that you have something like this for
scenario-level before/after:

class MySteps < Cucumber::Steps # Same as Story runnner steps_for(:my)
 Before do
   # This block will run before all scenarios that use steps from MySteps
   # Any scenarios not using any of these will not have this block run
 end

 Given /bla bla/ do
 end
end

Aslak
> Right now I use the listeners to call a before_story and after_story and
> before_scenario.
>
> My Stories (Features) test the database as well as the return values of
> various calls, so the before_story sets up the database accessors via
> Sequel, putting them in global variables so I can easily access them from
> anywhere.
>
> In the before_scenario I for instance make sure the user is logged out and
> the database is cleared.
>
> --
> Jim Morris, http://blog.wolfman.com
>

On Aug 20, 2008, at 2:20 AM, Aslak Helles?y wrote:
>  (In Cucumber it''s Feature, not Story)
no offense, but while you''re being picky about names, I dont see too  
much difference between ''story'' and
''feature''
but ''cucumber'' is a really random meaningless name

On Wed, Aug 20, 2008 at 9:04 AM, Jonathan Linowes
<jonathan at parkerhill.com> wrote:
>
> On Aug 20, 2008, at 2:20 AM, Aslak Helles?y wrote:
>
>>  (In Cucumber it''s Feature, not Story)
>
> no offense, but while you''re being picky about names, I dont see
too much
> difference between ''story'' and
''feature''
I see them as very different.

User Stories are inputs to a development process and Features are the outputs.

When I''ve worked with FitNesse, we had stories on cards and a suite of
FitNesse tests. Sometimes a Story would come up in an iteration that
was an enhancement of an existing feature. In those cases we did not
add new FitNesse tests, but simply enhanced the existing ones instead.
So the FitNesse test suite grew to represent executable documentation
of an existing system, not a tracking system for stories over the
course of iterations.

Had we grouped all the FitNesse tests by the stories as they came in,
in which iteration, etc, etc, they would have been much more difficult
to navigate and maintain.

Automated scenarios live in the same place that FitNesse tests do.
Ideally, we would group them by Story going into an iteration and then
by Feature coming out, but we don''t really have a good way of doing
that.

Maybe the right approach would be to group them by neither Story nor
Feature, but rather by execution context. For example, right now I''ve
got stories that run one happy path scenario and one error path
scenario that run in-browser, accompanied by a more exhaustive set of
error path scenarios that run in-memory. These live in separate Story
files and are only coupled together by their names.

It would be nice if I could have a suite of in-browser scenarios, a
suite of in-memory scenarios that touch the full stack (in rails), and
possibly a suite of scenarios that touch only a given model. Then each
scenario can be tagged to a Story and a Feature, and the runner could
support running everything by Story, Feature or Execution Context,
thus supporting readability, navigability, etc, from a number of
useful perspectives.

WDYT?
> but ''cucumber'' is a really random meaningless name
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Wed, Aug 20, 2008 at 4:20 PM, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On Wed, Aug 20, 2008 at 9:04 AM, Jonathan Linowes
> <jonathan at parkerhill.com> wrote:
>>
>> On Aug 20, 2008, at 2:20 AM, Aslak Helles?y wrote:
>>
>>>  (In Cucumber it''s Feature, not Story)
>>
>> no offense, but while you''re being picky about names, I dont
see too much
>> difference between ''story'' and
''feature''
>
> I see them as very different.
>
> User Stories are inputs to a development process and Features are the
outputs.
>
That''s a brilliant description. Much better than these ramblings:
http://www.nabble.com/Re%3A--ANN--Cucumber-p18899320.html

I would add to that that the features, which are the outputs of the
development process, are the inputs to the outcomes. AKA Business
value.
These two posts complement that aspect nicely:

http://www.artima.com/weblogs/viewpost.jsp?thread=183405
http://sirenian.livejournal.com/2008/05/14/

Regarding Cucumber - yes, the name is completely meaningless, but a
couple of chicks who attended my presentation about it at Agile 2008
told me afterwards it made their mind drift... That''s good enough for
me.

Aslak
> When I''ve worked with FitNesse, we had stories on cards and a
suite of
> FitNesse tests. Sometimes a Story would come up in an iteration that
> was an enhancement of an existing feature. In those cases we did not
> add new FitNesse tests, but simply enhanced the existing ones instead.
> So the FitNesse test suite grew to represent executable documentation
> of an existing system, not a tracking system for stories over the
> course of iterations.
>
> Had we grouped all the FitNesse tests by the stories as they came in,
> in which iteration, etc, etc, they would have been much more difficult
> to navigate and maintain.
>
> Automated scenarios live in the same place that FitNesse tests do.
> Ideally, we would group them by Story going into an iteration and then
> by Feature coming out, but we don''t really have a good way of
doing
> that.
>
> Maybe the right approach would be to group them by neither Story nor
> Feature, but rather by execution context. For example, right now
I''ve
> got stories that run one happy path scenario and one error path
> scenario that run in-browser, accompanied by a more exhaustive set of
> error path scenarios that run in-memory. These live in separate Story
> files and are only coupled together by their names.
>
> It would be nice if I could have a suite of in-browser scenarios, a
> suite of in-memory scenarios that touch the full stack (in rails), and
> possibly a suite of scenarios that touch only a given model. Then each
> scenario can be tagged to a Story and a Feature, and the runner could
> support running everything by Story, Feature or Execution Context,
> thus supporting readability, navigability, etc, from a number of
> useful perspectives.
>
> WDYT?
>
>> but ''cucumber'' is a really random meaningless name
>>
>> _______________________________________________
>> 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
>

On Wed, Aug 20, 2008 at 7:49 AM, aslak hellesoy <aslak.hellesoy at
gmail.com>wrote:
>
> Regarding Cucumber - yes, the name is completely meaningless, but a
> couple of chicks who attended my presentation about it at Agile 2008
> told me afterwards it made their mind drift... That''s good enough
for
> me.
>
Aslak, please feel free to use whatever verbiage you choose. I just wanted
to mention that for some (including myself), such comments don''t
reflect
well on the speaker. Maybe I''m just showing my age. :)

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080820/34e1744d/attachment.html>

On Wed, Aug 20, 2008 at 5:32 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Wed, Aug 20, 2008 at 7:49 AM, aslak hellesoy <aslak.hellesoy at
gmail.com>
> wrote:
>>
>> Regarding Cucumber - yes, the name is completely meaningless, but a
>> couple of chicks who attended my presentation about it at Agile 2008
>> told me afterwards it made their mind drift... That''s good
enough for
>> me.
>
> Aslak, please feel free to use whatever verbiage you choose. I just wanted
> to mention that for some (including myself), such comments don''t
reflect
> well on the speaker. Maybe I''m just showing my age. :)
>
I can live with that.

If you really want to know the origin of the name, check out the bottom of
http://github.com/aslakhellesoy/cucumber/tree/master/README.textile

Let''s get back on topic.

Aslak
> ///ark
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

aslak hellesoy wrote:
> The RSpec Story runner is likely to be deprecated in favour of the new
> feature runner (temporarily called Cucumber).
> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>
> The RSpec Story runner will continue to exist for a while, I just
> wanted to let you know that future development and documentation
> efforts will be focused on Cucumber. Cucumber also has some
> documentation and examples on Github, more specifically:
>
> * How to use without Rails
> * How to use with Rails+Webrat
> * How to use with Watir
>
> Please let me know if you''d like to help out documenting Cucumber.
One
> thing that is missing is a migration guide from RSpec Story runner.
>   


Do you prefer to keep such documentation in the README or would a github
wiki be better?

-Ben

I agree with Pat also. But I think importantly we need a little 
tool/guide on converting the old stories to cucumber before any 
movement.

I''m currently evaluating moving our stories to cucumber. I''ll
see if I
can put something together that might help others (if its not already 
available?).

Also the word ''feature'' resolves so many issues I had with
stories and
how they mapped into my testing framework. Thanks Aslak!

--
Joseph Wilk
http://www.joesniff.co.uk

Josh Knowles wrote:
> On 8/19/08, Pat Maddox <pergesu at gmail.com> wrote:
>> I would prefer to merge it into RSpec whenever it''s ready.
> 
> For whatever its worth I agree with Pat.  Most of the short-comings of
> the existing story runner that Aslak describes in the Cucumber README
> are things that we at weplay have had to hack together.  Having some
> standardization for running a single scenario, or all scenarios, would
> make developing tools on-top of the framework that much easier.
> 
> Josh
> 
> --
> Josh Knowles
> phone: 509-979-1593
> email:  joshknowles at gmail.com
> web:    http://joshknowles.com
-- 
Posted via http://www.ruby-forum.com/.

aslak hellesoy wrote:
> 
> Of how you would use it. Assume that you have something like this for
> scenario-level before/after:
> 
> class MySteps < Cucumber::Steps # Same as Story runnner steps_for(:my)
>  Before do
>    # This block will run before all scenarios that use steps from MySteps
>    # Any scenarios not using any of these will not have this block run
>  end
> 
>  Given /bla bla/ do
>  end
> end
> 
> Aslak
> 
Ok here is an example from one of my current stories.... Modified to be
Cucumber-like, although I
see you put the Before and after in the steps, I''d p[refer them to be
global, but could live with
them in the steps class. Of course where would you put the scenarios before and
after? They probably
need to be global?

(Note I am not using Rails,this is an integration test against a Web Application
testing the full
stack using net/http and some helpers to wrap that. It can test remote servers,
It also uses Sequel
to test that the database gets setup properly, again a bunch of helpers lets me
inject data directly
into the database and test afterwards).

# setup several users each with their own web context
# setup global database accessor
BeforeFeature do
   # actual user names to login as
   user_names= %w(user50 user51 user52)

   $umap= {}
   $wr= {}
   user_names.each_with_index do |e, i|
     n= "user#{i+1}"
     $umap[n]= e
     $wr[n]=  WebRequest.new
   end

   $users= {}
   $loggedin= {}

   $db= MyDBHelper.new(''local'', false)
end

# logout the users
AfterFeature do
   $wr.each_value { |w| w.logout }
end

# called before each scenario
# to clean up any state conatianing globals used to communicate between steps
# and log out any user that was logged in during the previous Scenario
BeforeScenario do
   $wr.each_key do |u|
     $wr[u].logout if $loggedin[u]
   end

   $last_error= nil
   $roomid= nil
   $roomobjectid= nil
   $last_doc= nil
   $bagid= nil
end



-- 
Jim Morris, http://blog.wolfman.com

On Wed, Aug 20, 2008 at 6:24 PM, Ben Mabey <ben at benmabey.com>
wrote:
> aslak hellesoy wrote:
>> The RSpec Story runner is likely to be deprecated in favour of the new
>> feature runner (temporarily called Cucumber).
>> http://www.nabble.com/-ANN--Cucumber-td18876816.html
>>
>> The RSpec Story runner will continue to exist for a while, I just
>> wanted to let you know that future development and documentation
>> efforts will be focused on Cucumber. Cucumber also has some
>> documentation and examples on Github, more specifically:
>>
>> * How to use without Rails
>> * How to use with Rails+Webrat
>> * How to use with Watir
>>
>> Please let me know if you''d like to help out documenting
Cucumber. One
>> thing that is missing is a migration guide from RSpec Story runner.
>>
>
>
>
> Do you prefer to keep such documentation in the README or would a github
> wiki be better?
>
Good idea, I have moved the README.textile to
http://github.com/aslakhellesoy/cucumber/wikis/home

Everyone here is welcome to edit it. If you have concrete experience
(or wishes) about how to migrate existing stories to Cucumber this
would be the place to do it.

Aslak
> -Ben
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Hello,

I''ve been looking through the cucumber documentation and have a couple 
of questions.

I''m curious which of the disadvantages you list would be
impossible/very
difficult in the classic story runner. I''m just trying to envisage if 
Cucumber and the classic story runner where to co-exist what would the 
Cucumber plugin be able to do that the classic story runner could never 
realistically hope to achieve.

Also looking at one of your disadvantages:
* ''Limited colouring of output''
I''ve been playing around with patches here and there to improve the 
colour of the classic story runner formatters. Do you still see 
limitations in this as it is in edge?

My final question is about the Rspec book. I''ve no idea when this will 
be released or what pressures there are on publish deadlines. How much 
would this effect a move to Cucumber (avoiding having redundant story 
examples in the book when we all use Cucumber)?

Thanks,
--
Joseph Wilk
http://www.joesniff.co.uk
aslak hellesoy wrote:
> On Wed, Aug 20, 2008 at 6:24 PM, Ben Mabey <ben at benmabey.com>
wrote:
>>> * How to use without Rails
>> wiki be better?
>>
> 
> Good idea, I have moved the README.textile to
> http://github.com/aslakhellesoy/cucumber/wikis/home
> 
> Everyone here is welcome to edit it. If you have concrete experience
> (or wishes) about how to migrate existing stories to Cucumber this
> would be the place to do it.
> 
> Aslak
-- 
Posted via http://www.ruby-forum.com/.

On Aug 20, 2008, at 10:20 AM, David Chelimsky wrote:
>
> I see them as very different.
>
> User Stories are inputs to a development process and Features are  
> the outputs.
I decided to churn on this for a few days before responding. Actually  
I was going to let it drop, but kept thinking about it.

Given your observation (above) I see an analogy between Stores ->  
Features,   and Specs -> Tests, that is, I write specs as input, I  
develop the code, and tests are the outputs. Same code, different  
purpose.

You (or someone) named this framework rspec perhaps because
''spec'' is
more descriptive and accurate than ''test'', but more
importantly
because there is a large body of work and history with conventional  
QA and testing, and it was important to coin a new term (spec) to  
distinguish BDD from conventional testing. However, you can use test  
tools to do BDD (e.g. as many people has chosen to continue using  
Test Unit and shoulda rather than rspec for whatever reasons).

But with regard to stories vs features, there really isnt a legacy  
and baggage about the word ''story'', so changing the name to
''feature''
is mostly semantics.

Personally, I do not see a feature as separate from a story, because  
a feature means nothing without some context. Stories provide that  
context.  Scenarios provide the specifics. I might write and organize  
my stories by individual feature, but theres other ways as well:  
workflows, goals/objectives, different starting setups, user roles,  
and so on, all involving one or more sets of features.

I''m not trying to be argumentative, and I''m wholeheartedly  
appreciative of the work you and Alask and everyone does on this  
project. If anything, I''m just trying to sort all this out for myself.

On Fri, Aug 22, 2008 at 12:53 PM, Jonathan Linowes
<jonathan at parkerhill.com> wrote:
>
> On Aug 20, 2008, at 10:20 AM, David Chelimsky wrote:
>>
>> I see them as very different.
>>
>> User Stories are inputs to a development process and Features are the
>> outputs.
>
> I decided to churn on this for a few days before responding. Actually I was
> going to let it drop, but kept thinking about it.
>
> Given your observation (above) I see an analogy between Stores ->
Features,
>   and Specs -> Tests, that is, I write specs as input, I develop the
code,
> and tests are the outputs. Same code, different purpose.
>
> You (or someone) named this framework rspec perhaps because
''spec'' is more
> descriptive and accurate than ''test'', but more
importantly because there is
> a large body of work and history with conventional QA and testing, and it
> was important to coin a new term (spec) to distinguish BDD from
conventional
> testing.
Steven Baker named the framework rspec. I believe his motivation was
Uncle Bob saying "specify, don''t verify" when talking about
what TDD
and ATDD is about.

Sadly, "spec" has just as much baggage, if not more, as
"test" does.
These days we''re calling these things "code examples,"
(tongue
pressing into cheek) so maybe we should change the name to
rcodeexample?
> However, you can use test tools to do BDD (e.g. as many people has
> chosen to continue using Test Unit and shoulda rather than rspec for
> whatever reasons).
Agreed. Tools is tools. Process is process. (boat is boat ....)
> But with regard to stories vs features, there really isnt a legacy and
> baggage about the word ''story'', so changing the name to
''feature'' is mostly
> semantics.
User Stories have been around since the late 90''s. I''d say
that
qualifies them for legacy/baggage.
> Personally, I do not see a feature as separate from a story, because a
> feature means nothing without some context. Stories provide that context.
>  Scenarios provide the specifics. I might write and organize my stories by
> individual feature, but theres other ways as well: workflows,
> goals/objectives, different starting setups, user roles, and so on, all
> involving one or more sets of features.
>
> I''m not trying to be argumentative, and I''m
wholeheartedly appreciative of
> the work you and Alask and everyone does on this project. If anything,
I''m
> just trying to sort all this out for myself.
This is something that''s bugged me since rbehave first appeared (even
before we merged it into rspec). I''ve discussed this w/ Dan North a
few times and we''ve agreed on some aspects of this but not all. I
won''t speak for Dan here, but my experience tells me that there is not
a clean mapping of stories (the things that drive development) to
features (the things that exist in the system because they have
already been developed).

For example, imagine we''re working on a conference
organization/registration tool and way back in iteration 1 we had a
story about the organizer being able to see a report of conference
registrations (this may sound familiar if you saw my talk at
RailsConf).

Imagine that one of the conference organizers noted that a given
conference was reporting 100% full even though only 499 of the goal of
500 had registered. So a new story gets added suggesting that it
should not be rounded up to 100%.

So now we have two choices. We can add a new story file with a new
narrative and a single scenario, or we can crack open the existing
story file and add a single scenario.

In terms of the feature (which is the report), I see this as just
another scenario.

In terms of driving development and estimating effort, I see this as a
new User Story.

Does this clarify or further confuse?
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

David Chelimsky wrote:
> Agreed. Tools is tools. Process is process. (boat is boat ....)
And parts is parts.  Let''s not forget that:

http://www.youtube.com/watch?v=OTzLVIc-O5E

Jay

On Aug 24, 2008, at 4:18 PM, Jay Levitt wrote:
> David Chelimsky wrote:
>> Agreed. Tools is tools. Process is process. (boat is boat ....)
>
> And parts is parts.  Let''s not forget that:
>
> http://www.youtube.com/watch?v=OTzLVIc-O5E
>
> Jay

OT, reminds me of when, a while back, I was developing CAD software,
and had a potential customer call who told me (with a strong Boston  
accent)
their company designs pots.
"Oh, neat, what kind of pots, you mean cooking pots?" I asked.
"No, no," she replied, "machine ''pots'' "
Needless to say, I didnt win the client  :)


> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Aug 24, 2008, at 12:31 PM, David Chelimsky wrote:
>
> In terms of the feature (which is the report), I see this as just
> another scenario.
>
> In terms of driving development and estimating effort, I see this as a
> new User Story.
>
> Does this clarify or further confuse?
>>

I see your scenario of 499 registrants as a new feature of the  
existing story :)

On Mon, Aug 25, 2008 at 5:12 PM, Jonathan Linowes
<jonathan at parkerhill.com> wrote:
>
> On Aug 24, 2008, at 12:31 PM, David Chelimsky wrote:
>>
>> In terms of the feature (which is the report), I see this as just
>> another scenario.
>>
>> In terms of driving development and estimating effort, I see this as a
>> new User Story.
>>
>> Does this clarify or further confuse?
>>>
>
>
> I see your scenario of 499 registrants as a new feature of the existing
> story :)
>
In light of what David and I have said previously, I would express it
exactly the other way around:

"The scenarios in this user story describe an expansion of the
existing feature."

In other words, the story (and its scenarios) are inputs to the
development. The output is a fatter feature.

Aslak
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Aug 25, 2008, at 11:19 AM, aslak hellesoy wrote:
> On Mon, Aug 25, 2008 at 5:12 PM, Jonathan Linowes
> <jonathan at parkerhill.com> wrote:
>>
>> On Aug 24, 2008, at 12:31 PM, David Chelimsky wrote:
>>>
>>> In terms of the feature (which is the report), I see this as just
>>> another scenario.
>>>
>>> In terms of driving development and estimating effort, I see this  
>>> as a
>>> new User Story.
>>>
>>> Does this clarify or further confuse?
>>>>
>>
>>
>> I see your scenario of 499 registrants as a new feature of the  
>> existing
>> story :)
>>
>
> In light of what David and I have said previously, I would express it
> exactly the other way around:
>
> "The scenarios in this user story describe an expansion of the
> existing feature."
>
> In other words, the story (and its scenarios) are inputs to the
> development. The output is a fatter feature.
>
> Aslak
Aslak, so in terms of the cucumber runner and BDD development  
process, where would you add the scenario? reopen an existing .story  
file?
>
>>
>> _______________________________________________
>> 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

On Mon, Aug 25, 2008 at 5:37 PM, Jonathan Linowes
<jonathan at parkerhill.com> wrote:
>
> On Aug 25, 2008, at 11:19 AM, aslak hellesoy wrote:
>
>> On Mon, Aug 25, 2008 at 5:12 PM, Jonathan Linowes
>> <jonathan at parkerhill.com> wrote:
>>>
>>> On Aug 24, 2008, at 12:31 PM, David Chelimsky wrote:
>>>>
>>>> In terms of the feature (which is the report), I see this as
just
>>>> another scenario.
>>>>
>>>> In terms of driving development and estimating effort, I see
this as a
>>>> new User Story.
>>>>
>>>> Does this clarify or further confuse?
>>>>>
>>>
>>>
>>> I see your scenario of 499 registrants as a new feature of the
existing
>>> story :)
>>>
>>
>> In light of what David and I have said previously, I would express it
>> exactly the other way around:
>>
>> "The scenarios in this user story describe an expansion of the
>> existing feature."
>>
>> In other words, the story (and its scenarios) are inputs to the
>> development. The output is a fatter feature.
>>
>> Aslak
>
> Aslak, so in terms of the cucumber runner and BDD development process,
where
> would you add the scenario? reopen an existing .story file?
>
Yes, add it to an existing .feature file (or create a new one if the
story''s scenario don''t fit in an existing feature).

Aslak
>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Thu, Aug 21, 2008 at 6:08 PM, Joseph Wilk <lists at ruby-forum.com>
wrote:
> Hello,
>
> I''ve been looking through the cucumber documentation and have a
couple
> of questions.
>
Hi, Sorry for the late reply,
> I''m curious which of the disadvantages you list would be
impossible/very
> difficult in the classic story runner. I''m just trying to envisage
if
>From http://github.com/aslakhellesoy/cucumber/wikis - 10 means big
effort, 1 small. Relatively. Your opinion may differ.

    5: Hard to get started with. A special "all.rb" file must be
written before it can be used.
    3: No out of the box Rake support, which puts a lot of people off.
    3: No i18n, so if you want to write stories in a different
language than English you''re out of luck.
    8: Poor error reporting. No way to know on what line a plain text
story failed during execution or parsing.
    1: Limited colouring of output.
    5: No simple way to execute only one scenario.
    8: No command line tool to run stories.
    2: No easy before or after hooks.
    5: No highlighting of step parameters in the output
    2: No detection of ambiguous step names
> Cucumber and the classic story runner where to co-exist what would the
> Cucumber plugin be able to do that the classic story runner could never
I assume that by plugin you mean Rails plugin? (Cucumber is a
standalone library that *may* be used as a Rails plugin).
> realistically hope to achieve.
>
The Story runner could achieve this if someone put enough effort into
it. That would have to be someone other than me, because I don''t have
the time (or desire) to do it. Let''s say it''s up for grabs.
> Also looking at one of your disadvantages:
> * ''Limited colouring of output''
> I''ve been playing around with patches here and there to improve
the
> colour of the classic story runner formatters. Do you still see
> limitations in this as it is in edge?
>
That''s one of the easiest things to fix, and also one of the smallest
disadvantages IMO.
> My final question is about the Rspec book. I''ve no idea when this
will
> be released or what pressures there are on publish deadlines. How much
> would this effect a move to Cucumber (avoiding having redundant story
> examples in the book when we all use Cucumber)?
>
Regarding the book - we haven''t decided whether or not to cover
Cucumber.

In any case, *writing* stories/features for the Story runner will be
almost identical to Cucumber features.

On Tuesday I ported one of our projects at work over to Cucumber. Over
1000 steps. I ended up having to change almost nothing in the text or
step defs (except for resolving some duplicates and ambiguities that
Cucumber complains about where RSR says nothing). I have written up
what I did and will post it to the Cucumber wiki next week when I have
some time to proofread it.

Cheers,
Aslak
> Thanks,
> --
> Joseph Wilk
> http://www.joesniff.co.uk
> aslak hellesoy wrote:
>> On Wed, Aug 20, 2008 at 6:24 PM, Ben Mabey <ben at benmabey.com>
wrote:
>>>> * How to use without Rails
>>> wiki be better?
>>>
>>
>> Good idea, I have moved the README.textile to
>> http://github.com/aslakhellesoy/cucumber/wikis/home
>>
>> Everyone here is welcome to edit it. If you have concrete experience
>> (or wishes) about how to migrate existing stories to Cucumber this
>> would be the place to do it.
>>
>> Aslak
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

As the author of the original scenario runner, if Aslak has come up with a
nicer implementation - both in terms of design and hackability - then I say
chuck my one out and use his :)

As long as it is an easy adjustment (i.e. transparent or with an easy
migration) for users of the current scenario runner then I think we should
ship it in.

Cheers,
Dan

2008/8/20 Pat Maddox <pergesu at gmail.com>
> > What do you think is the best thing to do?
>
> I would prefer to merge it into RSpec whenever it''s ready.  One of
the
> strong points about RSpec is that it''s a complete BDD toolkit:
example
> framework for developer testing, feature runner for customer test, and
> the mock objects framework.  People can get started with one part of
> the toolkit, and gradually use the other pieces as their wants and
> needs develop.  I think it was a big win when RBehave merged into
> RSpec.  If Cucumber represents significant improvements over the
> current Story Runner, I''d like to see those improvements make it
into
> RSpec.
>
> Pat
> _______________________________________________
> 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/20080829/a3ddad9e/attachment.html>

At the risk of being a bit controversial...

2008/8/24 David Chelimsky <dchelimsky at gmail.com>
[...]
> Sadly, "spec" has just as much baggage, if not more, as
"test" does.
> These days we''re calling these things "code examples,"
(tongue
> pressing into cheek) so maybe we should change the name to
> rcodeexample?

Or rbehave?

The rbehave.org domain is available (I registered it some time ago), and
rspec has naturally evolved from its original goal of code-level specs to
become a full-stack behaviour description framework.

Just a thought.

With regard to the stories and features thing, I see a BDD-shaped story as
providing a context - and justification - for a feature:

As a [stakeholder]
*I want [a feature]
*So that [I get some benefit]

Before we started using this structure, a "story" would often just be
the
middle line, so it wasn''t immediately obvious who the stakeholder was
or why
they wanted the feature, which in turn would often lead to over-work,
under-work or just plain wrong-work. Of course the word "story" has
its own
baggage. In XP a story is "a placeholder/promise for a conversation",
and as
such could just be a title scribbled on a card. I wrote the story
article<http://dannorth.net/whats-in-a-story>to put this all in
context - if you ask 5 agile folks what a story is, you
will likely get 6 answers.

I agree that *the feature is the interesting thing*, and also that there may
be several stories about the same feature in different broad contexts. In
any event the scenarios provide the definition of "Done" for the
feature,
which is kind of the whole point. So I guess I''m saying I''m
ambivalent about
the story/feature distinction. I don''t look at stories as work units as
much
as a more formal description of (some aspect of) a feature.

After speaking with Aslak - and some FDD folks I met at Agile 2008 - I can
fully agree with organising stories by feature. In fact in Peter Coad''s
FDD
they have features within feature sets, within subject areas, which might
well map to stories within features within [not sure - subject areas?
themes? something broader anyway]. FDD features seem to be "thinner"
than
what I understand Aslak''s description of features to be.

One thing that makes me happy is that we seem to have consensus around the
word "scenario" - which is where the outside-in work really starts.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080829/ae43e517/attachment.html>

On 29 Aug 2008, at 19:37, Dan North wrote:
> 2008/8/24 David Chelimsky <dchelimsky at gmail.com>
> [...]
> Sadly, "spec" has just as much baggage, if not more, as
"test" does.
> These days we''re calling these things "code examples,"
(tongue
> pressing into cheek) so maybe we should change the name to
> rcodeexample?
>
> Or rbehave?
>
> The rbehave.org domain is available (I registered it some time  
> ago), and rspec has naturally evolved from its original goal of  
> code-level specs to become a full-stack behaviour description  
> framework.
or RubyDD

or RuBehave

:)

I actually really like calling them specs rather than tests, at a  
unit-testing level. It makes a real difference to me that I''m  
expressing a *specification* for the class I''m about to code - it  
makes it much more natural to do it before you write the  
implementation when it''s a spec rather than a test.

cheers,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080830/1887473a/attachment.html>

2008-08-30 17:02, Matt Wynne:
> RuBehave
Now _that''s_ cool!  I love it!

-- 
Tero Tilus ## 050 3635 235 ## http://www.tilus.net/koti/tero/

On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote:
> 2008-08-30 17:02, Matt Wynne:
>> RuBehave
>
> Now _that''s_ cool!  I love it!
Personally, I always liked the rbehave / rspec combo, of Mike Myers &  
Ali G.

Scott

On 30 Aug 2008, at 19:31, Scott Taylor wrote:
>
> On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote:
>
>> 2008-08-30 17:02, Matt Wynne:
>>> RuBehave
>>
>> Now _that''s_ cool!  I love it!
>
> Personally, I always liked the rbehave / rspec combo, of Mike Myers  
> & Ali G.
>
> Scott
:)

One of the main adoption barriers we had with rspec at the BBC was  
the uniquely British problem of ''rspec'' sounding, to the
uninitiated,
rather too much like ''arse peck''.

On Sun, Aug 31, 2008 at 6:56 AM, Matt Wynne <matt at mattwynne.net>
wrote:
> On 30 Aug 2008, at 19:31, Scott Taylor wrote:
>
>>
>> On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote:
>>
>>> 2008-08-30 17:02, Matt Wynne:
>>>>
>>>> RuBehave
>>>
>>> Now _that''s_ cool!  I love it!
>>
>> Personally, I always liked the rbehave / rspec combo, of Mike Myers
& Ali
>> G.
>>
>> Scott
>
> :)
>
> One of the main adoption barriers we had with rspec at the BBC was the
> uniquely British problem of ''rspec'' sounding, to the
uninitiated, rather too
> much like ''arse peck''.
I think that could be resolved with a CI-driven contraption that you
keep in your back pocket and gives you a little peck whenever the
build fails. WDYT?
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Fri, Aug 29, 2008 at 1:37 PM, Dan North <tastapod at gmail.com>
wrote:
> At the risk of being a bit controversial...
>
> 2008/8/24 David Chelimsky <dchelimsky at gmail.com>
> [...]
>>
>> Sadly, "spec" has just as much baggage, if not more, as
"test" does.
>> These days we''re calling these things "code
examples," (tongue
>> pressing into cheek) so maybe we should change the name to
>> rcodeexample?
I was really only joking.
> Or rbehave?
>
> The rbehave.org domain is available (I registered it some time ago), and
> rspec has naturally evolved from its original goal of code-level specs to
> become a full-stack behaviour description framework.
I think we''re not at the point where we can really play with the name
of the code-level framework. Changing rspec''s name would impact a lot
of people. Consider the following:

* RubySpec uses MSpec, based on RSpec.
* Ruby itself runs its build against RubySpec.
* NetBeans supports RSpec.
* TextMate''s official bundle repo includes an RSpec bundle.
* Numerous open source projects use rspec for code examples.
 * Including many rails plugins, so rails apps are depending on
plugins that depend on rspec.

I''m not saying it''s something that should never happen. But
we''re in a
time right now (IMO) where it''s both too late and too early to do it.
Too late because of wide usage and momentum. Too early because a) it''s
not deeply ingrained enough quite yet for users to accept the burden
of the name change and b) we don''t really have the
team/infrastructure/support system to make it an easy transition.
> Just a thought.
>
> With regard to the stories and features thing, I see a BDD-shaped story as
> providing a context - and justification - for a feature:
>
> As a [stakeholder]
> I want [a feature]
> So that [I get some benefit]
>
> Before we started using this structure, a "story" would often
just be the
> middle line, so it wasn''t immediately obvious who the stakeholder
was or why
> they wanted the feature, which in turn would often lead to over-work,
> under-work or just plain wrong-work. Of course the word "story"
has its own
> baggage. In XP a story is "a placeholder/promise for a
conversation", and as
> such could just be a title scribbled on a card. I wrote the story article
to
> put this all in context - if you ask 5 agile folks what a story is, you
will
> likely get 6 answers.
>
> I agree that the feature is the interesting thing, and also that there may
> be several stories about the same feature in different broad contexts. In
> any event the scenarios provide the definition of "Done" for the
feature,
> which is kind of the whole point. So I guess I''m saying
I''m ambivalent about
> the story/feature distinction. I don''t look at stories as work
units as much
> as a more formal description of (some aspect of) a feature.
>
> After speaking with Aslak - and some FDD folks I met at Agile 2008 - I can
> fully agree with organising stories by feature.
Stories? Do you mean scenarios?
> In fact in Peter Coad''s FDD
> they have features within feature sets, within subject areas, which might
> well map to stories within features within [not sure - subject areas?
> themes? something broader anyway]. FDD features seem to be
"thinner" than
> what I understand Aslak''s description of features to be.
It seems that there is no word that is baggage-free. I think that
trying to think of this in terms of FDD would just add more confusion.

I do like Feature, in part, because it refers to the system. User
Stories are about how a user uses the system, where as a Feature is
about how the system responds to use. So Features are about system
behaviour. Maybe we should just go back to where we started, and call
these things (Stories/Features) ... ahem ... Behaviours. It''s a
thought.
> One thing that makes me happy is that we seem to have consensus around the
> word "scenario" - which is where the outside-in work really
starts.
Agreed. Stories and/or Features seem to be more about organization and
communication. Scenarios drive code development.

FWIW,
David
>
> Cheers,
> Dan
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Aug 31, 2008, at 7:56 AM, Matt Wynne wrote:
> On 30 Aug 2008, at 19:31, Scott Taylor wrote:
>
>>
>> On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote:
>>
>>> 2008-08-30 17:02, Matt Wynne:
>>>> RuBehave
>>>
>>> Now _that''s_ cool!  I love it!
>>
>> Personally, I always liked the rbehave / rspec combo, of Mike  
>> Myers & Ali G.
>>
>> Scott
>
> :)
>
> One of the main adoption barriers we had with rspec at the BBC was  
> the uniquely British problem of ''rspec'' sounding, to the
> uninitiated, rather too much like ''arse peck''.
with cucumber? ouch!
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Aug 31, 2008, at 9:39 AM, David Chelimsky wrote:
> Agreed. Stories and/or Features seem to be more about organization and
> communication. Scenarios drive code development.
+1
I also like to organize them into workflows, tasks, goals
Which makes me think maybe the scenario should be a more independent,  
reusable item

On Sun, Aug 31, 2008 at 9:02 AM, Jonathan Linowes
<jonathan at parkerhill.com> wrote:
>
> On Aug 31, 2008, at 9:39 AM, David Chelimsky wrote:
>
>> Agreed. Stories and/or Features seem to be more about organization and
>> communication. Scenarios drive code development.
>
> +1
> I also like to organize them into workflows, tasks, goals
> Which makes me think maybe the scenario should be a more independent,
> reusable item
We''ve talked about a tagging scheme that would allow you run scenarios
in any logical combinations, but unless we want to go to
one-scenario-per-file (which I, personally, don''t), we still need a
default organization scheme.

WDYT?

I find pronouncing the R with a piratey ''arrrrr spec'' helps
avoid any
arse or peck embarrassment.

I''m still struggling with how to pronounce rspec in Japanese.
The best I''ve managed is ''l spec''
All these darn r''s :)
--
Joseph Wilk
http://www.joesniff.co.uk

Matt Wynne wrote:
> On 30 Aug 2008, at 19:31, Scott Taylor wrote:
> 
>>
>> Scott
> 
> :)
> 
> One of the main adoption barriers we had with rspec at the BBC was
> the uniquely British problem of ''rspec'' sounding, to the
uninitiated,
> rather too much like ''arse peck''.
-- 
Posted via http://www.ruby-forum.com/.

On Sat, Aug 30, 2008 at 2:31 PM, Scott Taylor <mailing_lists at
railsnewbie.com
> wrote:
>
> On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote:
>
>  2008-08-30 17:02, Matt Wynne:
>>
>>> RuBehave
>>>
>>
>> Now _that''s_ cool!  I love it!
>>
>
> Personally, I always liked the rbehave / rspec combo, of Mike Myers &
Ali
> G.
>
>
Isn''t Ali G one of those "We ain''t got no RSpec, all we
got is the Rails
console." guys <G>
-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080904/b0c1ad36/attachment.html>

On Thu, Sep 4, 2008 at 3:37 PM, Rick DeNatale <rick.denatale at gmail.com>
wrote:
> On Sat, Aug 30, 2008 at 2:31 PM, Scott Taylor
> <mailing_lists at railsnewbie.com> wrote:
>>
>> On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote:
>>
>>> 2008-08-30 17:02, Matt Wynne:
>>>>
>>>> RuBehave
>>>
>>> Now _that''s_ cool!  I love it!
>>
>> Personally, I always liked the rbehave / rspec combo, of Mike Myers
& Ali
>> G.
>>
>
I lost the beginning of this thread...

A crude migration guide is available here:
http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories

Aslak
> Isn''t Ali G one of those "We ain''t got no RSpec, all
we got is the Rails
> console." guys <G>
> --
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denhaven2.com/
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>