[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:
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
>


More information about the rspec-users mailing list