[rspec-users] story vs feature (was Documentation for Plain-Text Stories)
dchelimsky at gmail.com
Sun Aug 24 12:31:59 EDT 2008
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
> 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
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
> 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
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
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
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
More information about the rspec-users