[rspec-users] Documentation for Plain-Text Stories
Matt Wynne
aidy lewis
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
> _______________________________________________
> rspec-users mailing list
> rspec...@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Matt Wynne
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
Joseph Wilk
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
aslak hellesoy
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
Matt Wynne
> 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?
aslak hellesoy
>>
>> 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
Matt Wynne
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
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.
aslak hellesoy
> 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
aidy lewis
2008/8/18 aslak hellesoy <aslak.h...@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
aslak hellesoy
> Hi Aslak
>
>
> 2008/8/18 aslak hellesoy <aslak.h...@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 lewis
> 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?
aslak hellesoy
> 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 lewis
2008/8/18 aslak hellesoy <aslak.h...@gmail.com>:
>
> What do you mean by expand?
>
> Aslak
>
I was going to give a more detailed example...
aslak hellesoy
> Aslak
>
> 2008/8/18 aslak hellesoy <aslak.h...@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 lewis
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.
--
Sent from Google Mail for mobile | mobile.google.com
Aslak Hellesøy
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
Jim Morris
>
> 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
David Chelimsky
> 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 :)
aslak hellesoy
> 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
> 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.
Aslak Hellesøy
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
Pat Maddox
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
Josh Knowles
> 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: joshk...@gmail.com
web: http://joshknowles.com
Jim Morris
>
> 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
Aslak Hellesøy
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
Aslak Hellesøy
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
aslak hellesoy
> 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)
>>
>
>
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.
Jonathan Linowes
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
David Chelimsky
<jona...@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?
aslak hellesoy
> On Wed, Aug 20, 2008 at 9:04 AM, Jonathan Linowes
> <jona...@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
Mark Wilden
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.
///ark
aslak hellesoy
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
Ben Mabey
> 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
>
> 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
>
> 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
Joseph Wilk
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 <per...@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: joshk...@gmail.com
> web: http://joshknowles.com
--
Posted via http://www.ruby-forum.com/.
Jim Morris
>
> 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
aslak hellesoy
> 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
Joseph Wilk
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 <b...@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/.
Jonathan Linowes
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.
David Chelimsky
<jona...@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?
Jay Levitt
> 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
Jonathan Linowes
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 :)
Jonathan Linowes
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 :)
aslak hellesoy
<jona...@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
Jonathan Linowes
On Aug 25, 2008, at 11:19 AM, aslak hellesoy wrote:
> On Mon, Aug 25, 2008 at 5:12 PM, Jonathan Linowes
> <jona...@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?
aslak hellesoy
<jona...@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
>> <jona...@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
aslak hellesoy
> 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
Dan North
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
Dan North
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.
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. 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
Matt Wynne
2008/8/24 David Chelimsky <dchel...@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.
Tero Tilus
> RuBehave
Now _that's_ cool! I love it!
--
Tero Tilus ## 050 3635 235 ## http://www.tilus.net/koti/tero/
Scott Taylor
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
Matt Wynne
>
> 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'.
David Chelimsky
> 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?
David Chelimsky
> At the risk of being a bit controversial...
>
> 2008/8/24 David Chelimsky <dchel...@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
Jonathan Linowes
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!
Jonathan Linowes
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
David Chelimsky
<jona...@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?
Joseph Wilk
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/.
Rick DeNatale
Personally, I always liked the rbehave / rspec combo, of Mike Myers & Ali G.
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!
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/
aslak hellesoy
> On Sat, Aug 30, 2008 at 2:31 PM, Scott Taylor
> <mailin...@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/
>