[rspec-devel] Stories vs. examples

Jake Howerton jake.howerton at gmail.com
Wed Nov 7 12:41:35 EST 2007


You could even take out the word link

When user clicks Manage Local Partners

Then implement the step as clicking a link w/ that text in a browser,
or clicking a button w/ that label in a desktop GUI.  I guess the
issue is more of a diminishing returns one.  Should you spend extra
time abstracting your stories away from implementation that you cannot
even forsee planning, and if so why?

Obviously the situation is really different if you are developing a
desktop client and web interface simultaneously or it is planned in a
short period of time.

Jake


> Scenario: visit partners list
>                Given user is authenticated as admin
>                And user is at manage library page
>
>                When user clicks Manage Local Partners link
>
>                Then user is brought to partners list
>
> ????
>
> WDYT?
>
> FWIW, I think that these sort of navigational scenarios should be
> limited, but I don't think they should be excluded.
>
> Cheers,
> David
>
>
> >
> > Jake
> >
> > On Nov 7, 2007 12:08 PM, Daniel De Aguiar
> >
> > <ddeaguiar at archcreekconsulting.com> wrote:
> > >
> > > Stories should be technology agnostic. I don't think form references, for
> > > example, have a place in them.
> > >
> > > I think technology-specific interaction story information is best captured
> > > in a different way, particularly in a "non-executable" format.
> > >
> > > - Dan
> > >
> > > On Nov 7, 2007, at 10:28 AM, "Dan North" <tastapod at gmail.com> wrote:
> > >
> > >
> > > Exactly. The behaviour description works in conjunction with other material
> > > that help with the non-behavioural aspects, like screen layouts or design
> > > guidelines. You would probably have a lo-fi mock-up of the login screen
> > > (just a drawing) with the User and Password fields and Login button
> > > labelled. Then the story would refer to those elements.
> > >
> > >
> > > On 11/7/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On Nov 7, 2007 2:04 AM, Matthijs Langenberg <mlangenberg at gmail.com> wrote:
> > > > > Would this also mean that the guy writing the story is defining the
> > > > > functional part of the GUI?
> > > > > Since it's the most outer layer of the system, would that be described
> > > in a
> > > > > story first?
> > > > > Like: "Given a user and a form with a button, when a user clicks the
> > > button,
> > > > > then the world should come to an end."
> > > >
> > > > There should likely be both interaction stories like that AND business
> > > > rule stories, like the one Dan uses in
> > > > http://dannorth.net/2007/06/introducing-rbehave . If every story takes
> > > > you through every step, they all become too big IMO.
> > > > _______________________________________________
> > > > 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
> > >
> > _______________________________________________
> > 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