[rspec-devel] Stories vs. examples
aslak.hellesoy at gmail.com
Tue Nov 6 16:13:42 EST 2007
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?
Stories is a way for domain experts (who don't necessarily know Ruby)
to express how they would like the software that doesn't exist to
For example, describing the business rules for whether someone should
be granted credit and how much based on age, gender, balance etc.
Or what should happen when you follow steps X, Y, Z in a business process.
It's a way to describe overall system behaviour with words without
even thinking about objects and classes (what domain experts care -
even know about - those anyway)
> Are stories supposed to be comprehensive enough to pass a rigorous
Do you mean the heckle tool? It depends how much effort you want to
put into making your code bugfree. It's an interesting idea.
> > ------------------------------
> > 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
More information about the rspec-devel