[rspec-users] Documentation for Plain-Text Stories

aslak hellesoy aslak.hellesoy at gmail.com
Wed Aug 20 10:49:52 EDT 2008

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:

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


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


> 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.
>> 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

More information about the rspec-users mailing list