[rspec-users] Are you writing "imperative" or "declarative" scenarios in your stories?

Zach Dennis zach.dennis at gmail.com
Sun May 11 19:49:31 EDT 2008


On Sun, May 11, 2008 at 5:01 PM, Ben Mabey <ben at benmabey.com> wrote:

> Hey all,
> I just found Bryan Helmkamp's (of webrat fame) slides on a presentation he
> did at GoRuCo 2008:
>
> http://www.brynary.com/2008/4/26/story-driven-development-slides-posted
>
> On slides 21-24 he talks about writing good stories and shows gives two
> examples.. the way not to do it and the way to do it.  You can also see the
> video of the presentation at confreaks (
> http://goruco2008.confreaks.com/01_helmkamp.html -- jump to 13:24 to see
> where he talks about the two examples.)  The first is what he calls an
> imperative example:
>
> ----------------------------------------------------------------------------
> Scenario: Reject duplicate names
>
> Given I am on the Developers page
>
> When I click the Add Developer button
>
> Then I should see the Add Developer page
>
> When I enter the first name Zed
> And I enter the last name Shaw
> And I click the Create Developer button
>
> Then I should see the message "Zed was created"
> And the Developers list should contain Zed Shaw
>
> When I enter the first name Zed
>
> And I enter the last name Shaw
> And I click the Create Developer button
>
> Then I should see an error "There can be only one Zed Shaw"
>
> ----------------------------------------------------------------------------
>
> The second is a declarative example and the same scenario reads like:
>
>
> ----------------------------------------------------------------------------
> Scenario: Reject duplicate names
>
> Given there is a developer Zed Shaw
>
> When I try to add a developer named Zed Shaw
>
> Then I should see an error "There can be only one Zed Shaw"
>
> ----------------------------------------------------------------------------
>
> Bryan argues that the imperative version is a poor choice because it is
> too coupled to the implementation;  keeping a scenario up to date with
> future maintenance changes may be a pain when you have to add or remove
> fields.  Additionally, the declarative version removes all of the noise so
> that the most important features of that story stand out.
> The imperative version looks like the "detailed scenarios" that David
> talked about at his ETEC slides (
> http://blog.davidchelimsky.net/articles/2008/04/01/etec-slides.)  On slide
> #75 David gives a good overview of the pros and cons of this style.  The
> pros mentioned are that they are easier to write and easier to change.
>
> While my stories may not read quite as bad as the example presented by
> Bryan I have been going down more of the imperative/detailed scenario route
> the majority of the time.  I have done this due to the high reuse of steps
> that it enables.  I haven't ran into maintenance issues with them yet but I
> can understand that point.  The more and more I think about it the more I
> agree with Bryan though.  The declarative version does feel a lot better and
> seems to keep the salient points more prominent.  Keeping the stories small,
> I think, is also more in line with the typical user stories in XP and other
> agile methodologies.  (I would like to see someone stick the first example
> on a 3x5 card :). )
> I did Use Cases (Alistair Cockburn style) on a project several years ago
> and I remember that revealing anything about the interface or implementation
> was a big no no.  I realize that user stories != use cases so I'm trying to
> find a balance between UI based stories and more declarative stories that
> don't reveal the implementation.  The funny thing is that I started out
> doing more declarative stories but my current customer kept wanting to write
> stories dealing with how the forms worked.  It seemed silly to fight the
> customer on this since the app will always be a web app.. so maybe it is
> just a balancing act we have to play on a case by case basis?
>
> I'm curious what everyone else on this list has been doing in this regard.
>  Are you writing declarative scenarios all the time?  Or are you reusing a
> lot of your steps with detailed scenarios?  A little bit of both maybe?  If
> so, how do you decide which type of scenario to use in a given case?  Any
> other thoughts on this matter?
>

I've been doing both with more scenarios leaning towards imperative than
declarative.  I find that my stories tend to be more of a mixture of the
imperative/declarative styles mentioned. For example I would have probably
written:

----------------------------------------------------------------------------
Scenario: Reject duplicate names

Given there is a developer named Zed Shaw in the system
And a user at the add a developer page
When they enter the first name Zed
And they enter the last name Shaw
And they click the Create Developer button
Then they should see an error "There can be only one Zed Shaw"
-------------------------------------------------------------------------------------

I think there are other benefits of going the declarative route as well,
such as creating a nicer set of re-usable helper methods sooner. When you
have more granular steps it seems there is less pain and discomfort upfront
associated with writing less re-usable pieces of code.  When you go the
declarative route all of your code is pushed together without the granular
step boundaries, forcing you to face up and extract out methods which reveal
the intent of the step.


--
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080511/5be11a13/attachment-0001.html>


More information about the rspec-users mailing list