On Mon, Apr 6, 2009 at 3:59 PM, Zach Dennis <zach.den...@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 12:36 PM, Mark Wilden <m...@mwilden.com> wrote:
>> On Mon, Apr 6, 2009 at 8:02 AM, James B. Byrne <byrn...@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@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@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
