On: Mon, 6 Apr 2009 09:36:50 -0700, Mark Wilden <[email protected]>
wrote:
> On Mon, Apr 6, 2009 at 8:02 AM, James B. Byrne
> <[email protected]> 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.
I venture that few solitary scenarios ever say much about the
success of the application. This example is only a single
(incomplete and somewhat contrived) scenario within a feature that
itself is but one of several that describe just one aspect of an
application. I do not think that one can lay too much weight upon
it.
>
> 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.'
Which clause serves as shorthand after what constitutes "all
required registration data" is defined elsewhere. Some of the
detail is provided to set up the scenario. Perhaps there are better
ways of accomplishing this but this practice serves and is neither
obscure nor overwhelmingly detailed.
> To me, this doesn't communicate anything meaningful to business.
> It's akin to 'Then it should work'.
Well, perhaps I have missed the point again. Nonetheless, this sort
of approach seems to provide me with a reasonable balance between
too much detail:
inputs "[email protected]" in the email box
inputs "Jeffery Q. Nameless" in the user name field
clicks on "Update"
And too little:
Given an application home page
When a visitor visits the application
Then they see "Welcome to X"
And they see a login field.
>
> 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?
Whether my current practice is right or wrong I do not know, but I
am finding that much of the implementation detail has migrated from
the scenarios into the step definitions. I find that I am using the
scenarios to drive the functional aspects of the application. At the
moment for instance I am dealing with this scenario:
...
When we visit the new entity page
And we enter valid entity data
And we fill in "Common Name" with "Short N"
And we press create
Then the entity named "Short N" should have an alias "short n"
Now this last clause drives this step:
When /the entity named "([^\"]*)" should have an alias "([^\"]*)"/ do
|name,aka|
my_identifiers = Entity.find_by_entity_common_name!(
name.hll_normalise).identifiers
...
end
The mix of granularity,
And we enter valid entity data
And we fill in "Common Name" with "Short N"
And we press create
Then the entity named "Short N" should have an alias "short n"
removes the clutter of background detail and focuses on the bit of
functionality that I want to explore here, the creation of an alias.
It may not be canonical usage, but it is working for me. As I
obtain greater skills and experience then no doubt my practices will
evolve.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:[email protected]
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
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
