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

On: Mon, 6 Apr 2009 09:36:50 -0700, 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
>
> 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 "x at y.com" 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: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