[rspec-devel] Stories vs. examples

Daniel De Aguiar ddeaguiar at archcreekconsulting.com
Wed Nov 7 17:05:34 EST 2007


In this case, the scenario is around the admins ability to retrieve local
partner info once they are logged in.

A simplified example:

Scenario: admin can retrieve local partner data
  Given a user is authenticated as an admin

  The user is able to retrieve a listing of local partners.


To me this captures the intent of the high-level requirement without
committing to an implementation early. To me stories are about 'What'  is
wanted (requirements) as opposed to 'How' it is done (implementation).

After further conversations with the users where the requirements are
explored in detail, the appropriate implementation is decided upon (i.e,
forms, page flows, fields, etc...). I would then focus on capturing these
implementation-specific details in traditional rspec tests.

Just my two cents...

-Dan

On 11/7/07, Jake Howerton <jake.howerton at gmail.com> wrote:
>
> Dan,
>
> I am not sure about that, when I am looking at writing a story for a
> web app, if I try and abstract the browser out of it, it stops making
> sense.
>
> You need to be sufficiently close to the metal to drive the
> implementation.
>
> Scenario: get index
>                 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 index
>
> Here is an example from an app I am working on.  The language 'clicks'
> and 'link' expressly imply that I am using a browser interface.
> I can definitely swap out the step implementation for safariwatir vs
> rails integration tests still.   How would you write a story like
> this?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071107/473d591b/attachment-0001.html 


More information about the rspec-devel mailing list