[rspec-users] story vs feature (was Documentation for Plain-Text Stories)

David Chelimsky dchelimsky at gmail.com
Sun Aug 31 09:39:56 EDT 2008


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
>


More information about the rspec-users mailing list