Would this also mean that the guy writing the story is defining the functional part of the GUI?<div>Since it's the most outer layer of the system, would that be described in a story first?</div><div>Like: "Given a user and a form with a button, when a user clicks the button, then the world should come to an end."
</div><div><br class="webkit-block-placeholder"></div><div>(I'm waiting for a book to come out, describing all this very cool stuff.)</div><div><div><br><div class="gmail_quote">On Nov 6, 2007 10:34 PM, Jake Howerton <
<a href="mailto:jake.howerton@gmail.com">jake.howerton@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This makes me wonder if some sort of bug tracking system could be
<br>integrated into the browser story editor where testers/customers could<br>enter the passing and failing story.<br><br>Bug Scenario: bad addition to cart<br> Given user has two apples in cart<br><br> When user adds two apples to cart
<br><br> Then user has three apples in cart<br><br>Expected Scenario: proper addition to cart<br> Given user has two apples in cart<br><br> When user adds two apples to cart<br><br> Then user has four apples in cart<br><br>
When you fix the bug you can promote the expected scenario to a first<br>class scenario ( or merge it with the one that did not cover the bug<br>properly), and store the bug regression stories somewhere to ensure<br>they do not fail in the future.
<br><br>WDYT?<br><font color="#888888"><br>Jake<br></font><div><div></div><div class="Wj3C7c"><br>On Nov 6, 2007 4:25 PM, aslak hellesoy <<a href="mailto:aslak.hellesoy@gmail.com">aslak.hellesoy@gmail.com</a>> wrote:
<br>> On Nov 6, 2007 7:39 PM, Alvin Schur <<a href="mailto:a.schur@nucleus.com">a.schur@nucleus.com</a>> wrote:<br>> > Are stories intended to mean "it worked in one case" to indicate a<br>> > feature is present instead of being an exhaustive description of how
<br>> > edge cases are handled?<br>> ><br>><br>> Ideally, yes. You'll typically have one scenario for each edge case. A<br>> story has many scenarios (which again have many steps - G/W/T)<br>><br>
> Aslak<br>><br>> > Are stories supposed to be comprehensive enough to pass a rigorous<br>> > "heckling"?<br>> ><br>> > Thanks,<br>> ><br>> > Alvin.<br>> > > ------------------------------
<br>> > ><br>> > > Message: 9<br>> > > Date: Tue, 6 Nov 2007 13:43:23 +0000<br>> > > From: "Dan North" <<a href="mailto:tastapod@gmail.com">tastapod@gmail.com</a>><br>> > > Subject: Re: [rspec-devel] Stories vs. examples
<br>> > > To: rspec-devel <<a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a>><br>> > > Message-ID:<br>> > > <<a href="mailto:d559d8430711060543g5d8954fbu157afcc177e847a1@mail.gmail.com">
d559d8430711060543g5d8954fbu157afcc177e847a1@mail.gmail.com</a>><br>> > > Content-Type: text/plain; charset="iso-8859-1"<br>> ><br>> > ><br>> > > Hi Ian.<br>> > ><br>
> > > I find it helps to think about the audience for your documentation. (It is<br>> > > documentation after all, it just happens to run, which is rather nice.)<br>> > ><br>> > > For the specs, the audience is developers. They want to know what an object
<br>> > > of a particular type - or more specifically in a particular role - does,<br>> > > which other objects it interacts with and why. This audience wants to see<br>> > > progress without leaving their IDE or editor, which is why we put effort
<br>> > > into making TextMate plugins and why we want to play nice with all the<br>> > > Test::Unit runners.<br>> > ><br>> > > For the stories, the audience is testers, analysts and ultimately the
<br>> > > various stakeholders who are requesting the features. They want to know what<br>> > > the system does and how to interact with it to get work done. They don't<br>> > > really care what happens under the hood. Typically they are non-technical
<br>> > > (or less technical than developers) which is why we think there is so much<br>> > > value in making their documentation look like documentation - just plain<br>> > > words on a page. Even better, if you can give them green words on a page
<br>> > > when the feature is implemented and working, or red words on a page when the<br>> > > feature isn't working, or grey words for unimplemented features, they can<br>> > > see progress in a living document. Now make that document editable, like a
<br>> > > regular document, and you are well on your way to acceptance testing<br>> > > Nirvana.<br>> > ><br>> > > So the process (described as "outside in" as opposed to "top down" or
<br>> > > "bottom up") starts by expressing a feature request as a story, driving out<br>> > > the scenarios that define "done" for that story and automating the steps<br>> > > that make up the scenarios. Then you use code-level examples to drive
<br>> > > inwards (that word "drive" again) from the outermost objects that the steps<br>> > > identified. All the time you want to implement just enough behaviour to get<br>> > > the steps to work, to drive the scenarios. Then you're done and you go to
<br>> > > the pub for a well-earned drink. Hence "beer-driven development".<br>> > ><br>> > > Hope that helps,<br>> > > Dan<br>> > ><br>> > > On 11/6/07, Ian Dees <
<a href="mailto:undees@gmail.com">undees@gmail.com</a>> wrote:<br>> > ><br>> > >> Hi, all.<br>> > >><br>> > >> I'm posting a philosophical question here, rather than cluttering up
<br>> > >> the tracker for the patch where it originated.<br>> > >><br>> > >> Quoth David, in response to some fuzzy thinking on my part:<br>> > >><br>> > >><br>
> > >>> Stories are not just another way to express examples - they're a<br>> > >>><br>> > >> completely different animal.<br>> > >><br>> > >> The offending clause of mine: "stories are another way to write your
<br>> > >> tests.... examples are meant for small, targeted descriptions of your<br>> > >> code's behavior... stories are suited to longer, more detailed<br>> > >> narratives."
<br>> > >><br>> > >> The intent wasn't to say that stories are a different syntax for<br>> > >> examples; it was that stories and examples are two different syntaxes<br>> > >> for two different test-writing purposes. But now I'm wondering if I
<br>> > >> even have _that_ right.<br>> > >><br>> > >> In Rails-land, the distinction is much clearer: you typically see<br>> > >> examples for testing code, and stories for testing applications (in
<br>> > >> the blog posts I've read, anyway).<br>> > >><br>> > >> But in GUI-land, the picture blurs a great deal: you're always testing<br>> > >> applications, but sometimes you're giving a tiny example of how one
<br>> > >> feature works, and at other times you're writing a story about several<br>> > >> steps of an interaction between the customer and the UI.<br>> > >><br>> > >> Anyone want to jump into these muddy waters?
<br>> > >> _______________________________________________<br>> > >> rspec-devel mailing list<br>> > >> <a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a><br>> > >>
<a href="http://rubyforge.org/mailman/listinfo/rspec-devel" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-devel</a><br>> > >><br>> > >><br>> ><br>> > _______________________________________________
<br>> > rspec-devel mailing list<br>> > <a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a><br>> > <a href="http://rubyforge.org/mailman/listinfo/rspec-devel" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-devel
</a><br>> ><br>> _______________________________________________<br>> rspec-devel mailing list<br>> <a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a><br>> <a href="http://rubyforge.org/mailman/listinfo/rspec-devel" target="_blank">
http://rubyforge.org/mailman/listinfo/rspec-devel</a><br>><br>_______________________________________________<br>rspec-devel mailing list<br><a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/rspec-devel" target="_blank">
http://rubyforge.org/mailman/listinfo/rspec-devel</a><br></div></div></blockquote></div><br></div></div>