rspec users - Apr 2009 - Best practices: How small to make > examples?

On: Sun, 5 Apr 2009 10:03:40 -0700, Mark Wilden <mark at mwilden.com>
wrote:
>
> On Sun, Apr 5, 2009 at 5:20 AM, David Chelimsky
> <dchelimsky at gmail.com> wrote:
>
>> Given I register for a conference
>> Then my name should be on the list of conference attendees
>> And the conference should be my list of conferences
>
> If I were describing ''register for a conference'' in this
scenario,
> then I would think it important to specify the steps that are used:
>
>  Given I am logged in
>  And I go to the registration page
>  And I fill in the email field
>  And I click "Register"
>  Then my name should be on the list of conference attendees
>  And the conference should be my list of conferences
>
> That''s the level of detail the story would have, so
that''s what I
> want to show works.
>
At the moment, I tend to take a "middle of the road" approach.
(Typically Canadian, eh?)

  Given user "myuser" is authenticated
  When they visit the registration page
   And they provide all required registration data
   And they choose "register"
  Then they should see a registration success message
   And ...

In the step definitions, one then chooses exactly what constitutes
/all required registration data/, or how /choose "register"/ is
implemented (button, link), or what a /registration success message/
looks like. If it is deemed absolutely essential to prove that a
specific input field is available in the view then this can be
slipped in under the /required ... data/ clause.

   And they provide all required registration data
   And they enter the email address "myuser at example.com"

In my, admittedly limited, experience this approach gives you all
the essential elements that the client needs to approve. Yet, it
still provides flexibility on how meeting the requirements are
implemented and tested, without breaking the scenario clauses.

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

On Mon, Apr 6, 2009 at 8:02 AM, James B. Byrne <byrnejb at harte-lyne.ca>
wrote:
>
> ?Given user "myuser" is authenticated
> ?When they visit the registration page
> ? And they provide all required registration data
> ? And they choose "register"
> ?Then they should see a registration success message
I have two issues with this:

1) How could this story be "acceptable"? In other words, how could
business say that it''s done? The success of this scenario would not
indicate very much about the success of the application.

2) There are different levels of granularity here. There are very
specific steps (''they visit the registration page'',
''they should see a
registration success message'') that relate to a specific URL or page
element. Then there is the catch-all ''all required registration
data.''
To me, this doesn''t communicate anything meaningful to business.
It''s
akin to ''Then it should work''.

Obviously, a scenario is not a formal requirements document.
Nevertheless, if what it asserts is too generic, how much benefit is
there in executing it?

///ark

On Mon, Apr 6, 2009 at 12:36 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Mon, Apr 6, 2009 at 8:02 AM, James B. Byrne <byrnejb at
harte-lyne.ca> wrote:
>>
>> ?Given user "myuser" is authenticated
>> ?When they visit the registration page
>> ? And they provide all required registration data
>> ? And they choose "register"
>> ?Then they should see a registration success message
>
You left out the "And..." which I believe James used to denote
anything else that needed to be done to ensure the registration was
successful. Maybe on purpose, maybe by accident, but it seems to have
impacted your response. Maybe what you responded with was exactly what
you meant to say, but it feels like a response made with haste.
> I have two issues with this:
>
> 1) How could this story be "acceptable"? In other words, how
could
> business say that it''s done? The success of this scenario would
not
> indicate very much about the success of the application.
>
> 2) There are different levels of granularity here. There are very
> specific steps (''they visit the registration page'',
''they should see a
> registration success message'') that relate to a specific URL or
page
> element. Then there is the catch-all ''all required registration
data.''
> To me, this doesn''t communicate anything meaningful to business.
It''s
> akin to ''Then it should work''.
>
> Obviously, a scenario is not a formal requirements document.
> Nevertheless, if what it asserts is too generic, how much benefit is
> there in executing it?
>
> ///ark
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Mon, Apr 6, 2009 at 3:59 PM, Zach Dennis <zach.dennis at gmail.com>
wrote:
> On Mon, Apr 6, 2009 at 12:36 PM, Mark Wilden <mark at mwilden.com>
wrote:
>> On Mon, Apr 6, 2009 at 8:02 AM, James B. Byrne <byrnejb at
harte-lyne.ca> wrote:
>>>
>>> ?Given user "myuser" is authenticated
>>> ?When they visit the registration page
>>> ? And they provide all required registration data
>>> ? And they choose "register"
>>> ?Then they should see a registration success message
>>
>
> You left out the "And..." which I believe James used to denote
> anything else that needed to be done to ensure the registration was
> successful.
The "And..." was a part of the "Then", and I was talking
about the
"When...".  Also, James talked about putting requirements in the step
definitions, and I believe my two concerns are still relevant in that
case.

However, admittedly I did gloss over "If it is deemed absolutely
essential to prove that a
specific input field is available in the view then this can be
slipped in under the /required ... data/ clause." But I still think
this represents a different viewpoint my own. The user''s input is
indeed essential to make a verifiable and descriptive scenario like
this one, IMO. Sorry if I distorted James message to try to reiterate
that point.

///ark
> Maybe on purpose, maybe by accident, but it seems to have
> impacted your response. Maybe what you responded with was exactly what
> you meant to say, but it feels like a response made with haste.
>
>> I have two issues with this:
>>
>> 1) How could this story be "acceptable"? In other words, how
could
>> business say that it''s done? The success of this scenario
would not
>> indicate very much about the success of the application.
>>
>> 2) There are different levels of granularity here. There are very
>> specific steps (''they visit the registration page'',
''they should see a
>> registration success message'') that relate to a specific URL
or page
>> element. Then there is the catch-all ''all required
registration data.''
>> To me, this doesn''t communicate anything meaningful to
business. It''s
>> akin to ''Then it should work''.
>>
>> Obviously, a scenario is not a formal requirements document.
>> Nevertheless, if what it asserts is too generic, how much benefit is
>> there in executing it?
>>
>> ///ark
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>