[rspec-devel] Stories vs. examples

Jake Howerton jake.howerton at gmail.com
Tue Nov 6 16:34:39 EST 2007


This makes me wonder if some sort of bug tracking system could be
integrated into the browser story editor where testers/customers could
enter the passing and failing story.

Bug Scenario: bad addition to cart
 Given user has two apples in cart

 When user adds two apples to cart

 Then user has three apples in cart

Expected Scenario: proper addition to cart
 Given user has two apples in cart

 When user adds two apples to cart

 Then user has four apples in cart

When you fix the bug you can promote the expected scenario to a first
class scenario ( or merge it with the one that did not cover the bug
properly),  and store the bug regression stories somewhere to ensure
they do not fail in the future.

WDYT?

Jake

On Nov 6, 2007 4:25 PM, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On Nov 6, 2007 7:39 PM, Alvin Schur <a.schur at nucleus.com> wrote:
> > Are stories intended to mean "it worked in one case" to indicate a
> > feature is present instead of being an exhaustive description of how
> > edge cases are handled?
> >
>
> Ideally, yes. You'll typically have one scenario for each edge case. A
> story has many scenarios (which again have many steps - G/W/T)
>
> Aslak
>
> > Are stories supposed to be comprehensive enough to pass a rigorous
> > "heckling"?
> >
> > Thanks,
> >
> > Alvin.
> > > ------------------------------
> > >
> > > Message: 9
> > > Date: Tue, 6 Nov 2007 13:43:23 +0000
> > > From: "Dan North" <tastapod at gmail.com>
> > > Subject: Re: [rspec-devel] Stories vs. examples
> > > To: rspec-devel <rspec-devel at rubyforge.org>
> > > Message-ID:
> > >       <d559d8430711060543g5d8954fbu157afcc177e847a1 at mail.gmail.com>
> > > Content-Type: text/plain; charset="iso-8859-1"
> >
> > >
> > > Hi Ian.
> > >
> > > I find it helps to think about the audience for your documentation. (It is
> > > documentation after all, it just happens to run, which is rather nice.)
> > >
> > > For the specs, the audience is developers. They want to know what an object
> > > of a particular type - or more specifically in a particular role - does,
> > > which other objects it interacts with and why. This audience wants to see
> > > progress without leaving their IDE or editor, which is why we put effort
> > > into making TextMate plugins and why we want to play nice with all the
> > > Test::Unit runners.
> > >
> > > For the stories, the audience is testers, analysts and ultimately the
> > > various stakeholders who are requesting the features. They want to know what
> > > the system does and how to interact with it to get work done. They don't
> > > really care what happens under the hood. Typically they are non-technical
> > > (or less technical than developers) which is why we think there is so much
> > > value in making their documentation look like documentation - just plain
> > > words on a page. Even better, if you can give them green words on a page
> > > when the feature is implemented and working, or red words on a page when the
> > > feature isn't working, or grey words for unimplemented features, they can
> > > see progress in a living document. Now make that document editable, like a
> > > regular document, and you are well on your way to acceptance testing
> > > Nirvana.
> > >
> > > So the process (described as "outside in" as opposed to "top down" or
> > > "bottom up") starts by expressing a feature request as a story, driving out
> > > the scenarios that define "done" for that story and automating the steps
> > > that make up the scenarios. Then you use code-level examples to drive
> > > inwards (that word "drive" again) from the outermost objects that the steps
> > > identified. All the time you want to implement just enough behaviour to get
> > > the steps to work, to drive the scenarios. Then you're done and you go to
> > > the pub for a well-earned drink. Hence "beer-driven development".
> > >
> > > Hope that helps,
> > > Dan
> > >
> > > On 11/6/07, Ian Dees <undees at gmail.com> wrote:
> > >
> > >> Hi, all.
> > >>
> > >> I'm posting a philosophical question here, rather than cluttering up
> > >> the tracker for the patch where it originated.
> > >>
> > >> Quoth David, in response to some fuzzy thinking on my part:
> > >>
> > >>
> > >>> Stories are not just another way to express examples - they're a
> > >>>
> > >> completely different animal.
> > >>
> > >> The offending clause of mine: "stories are another way to write your
> > >> tests.... examples are meant for small, targeted descriptions of your
> > >> code's behavior... stories are suited to longer, more detailed
> > >> narratives."
> > >>
> > >> The intent wasn't to say that stories are a different syntax for
> > >> examples; it was that stories and examples are two different syntaxes
> > >> for two different test-writing purposes.  But now I'm wondering if I
> > >> even have _that_ right.
> > >>
> > >> In Rails-land, the distinction is much clearer: you typically see
> > >> examples for testing code, and stories for testing applications (in
> > >> the blog posts I've read, anyway).
> > >>
> > >> But in GUI-land, the picture blurs a great deal: you're always testing
> > >> applications, but sometimes you're giving a tiny example of how one
> > >> feature works, and at other times you're writing a story about several
> > >> steps of an interaction between the customer and the UI.
> > >>
> > >> Anyone want to jump into these muddy waters?
> > >> _______________________________________________
> > >> rspec-devel mailing list
> > >> rspec-devel at rubyforge.org
> > >> http://rubyforge.org/mailman/listinfo/rspec-devel
> > >>
> > >>
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the rspec-devel mailing list