[rspec-users] DRY up story

Michael Latta lattam at mac.com
Fri Sep 26 14:48:23 EDT 2008

Thanks for the clarrification of your intent for the comment.  After  
reading the linked threads I have the following questions/comments:

1) All the responses to sharing story content get "use ruby" as the  
2( I understand you appear to find this adequate.  I do not.
3) Should I open a new ticket for my suggestion or just add to the  
existing ticket?

What I would like to see is something like a "feature" that is just  
for reuse.  The current scenario and feature in cucumber combine 2  
concepts: the definition of a scenario/feature and the execution of a  
scenario/feature.  This is like being unable to create a function  
without calling it immediately in place.  While I appreciate for the  
top level of control this is convenient and natural for the reader.   
It largely prevents reuse.  I would like a new keyword that just  
defines a sequence of steps as one step.  I want step definitions in  
the story language.

StepGiven: Log in as admin
	Given: I am registered as admin, David, secret
	When I log in with David, secret
	Then I should see "Welcome David"
	And I should see a link to "Manage Content"

Scenario: Admin clicks on "Manage Content"
	Given Log in as admin
	When I click on "Manage Content"
	Then I should see a link to "Go back to menu"

This would only execute the scenario once, unlike GivenScenario.  You  
can place StepGiven, and StepWhen, and StepThen in any file and they  
only define steps that can be used by other content.  They can  
reference steps created in either ruby or story language.  You can  
choose to present the nested steps or not.  In HTML output it could be  
expanded and collapsed.  In text output there could be an option to  
limit output nesting depth.

To make this fully functional there should be a Require: that allows  
files with step definitions to be required, solving most of your  
shared content objections for file management.  Content can be  
required and need not be executed unless so desired and referenced by  
a scenario.

It would require the title for the Steps to be regex expressions and  
variables dealt with in stories I guess.  But, when presenting to  
customers having shared content is important for validation of the  
specifications.  For acceptance testing one level may be enough, but  
for specifications there needs to be nesting and shared content that  
can be verified by the customer or their non-programmer representative  
or domain experts.  For reference the project I hope to use this on is  
expected to be 50-100 technical people.  We are going to really need  
readable specs for business logic, UI, and so on.

What do you think?


On Sep 25, 2008, at 8:52 AM, David Chelimsky wrote:

> On Thu, Sep 25, 2008 at 9:42 AM, Michael Latta <lattam at mac.com> wrote:
>> The problem I have with this reasoning is that the point of plain  
>> text
>> stories is to get more stakeholder involvement.  Being able to  
>> express
>> shared content in plain text allows the non-programmer reader to  
>> verify more
>> details (for example UI interactions within a high level story).  I  
>> would
>> like to be able to express the high level intent of the scenario  
>> and then
>> (still in readable english like text) describe the UI interactions  
>> for each
>> step, or the business logic details, or what ever should be  
>> verified by the
>> customer to be correct about the details.  Saying "you can always  
>> use ruby"
>> assumes the audience is programmers.
> I think you misunderstand what I wrote. I made no such assumption. I
> said very specifically that this was audience dependent and that if
> you're audience is customers you can look at it one way, but if it's
> just developers you can use the Ruby tools. I can see why you might be
> confused by "If you're a developer" rather than "if your audience is
> all developers," but that was the intent.
> In terms of ways of sharing content, there is some interesting
> discussion going on around Cucumber, which will replace Story Runner.
> Have a look at these:
> http://blog.davidchelimsky.net/2008/9/22/cucumber
> http://rspec.lighthouseapp.com/projects/16211/tickets/3
> Please feel free to join the conversation there, or on this list.
> Cheers,
> David
>> In most cases this is not the case for
>> several levels of detail on the kinds of projects I am working.
>> Michael
>> On Jun 24, 2008, at 2:31 PM, Rick DeNatale wrote:
>> On Tue, Jun 24, 2008 at 3:00 PM, David Chelimsky <dchelimsky at gmail.com 
>> >
>> wrote:
>>> On Jun 24, 2008, at 1:54 PM, Yi Wen wrote:
>>>> In David's presentation @ RailsConf, he has this example:
>>>> Story: measure progress towards registration goals
>>>> As a conference organizer
>>>> I want to see a report of registrations
>>>> So that I can measure progress towards registration goals
>>>> Scenario: one registration shows as 1%
>>>> Given a goal of 200 registrations
>>>> When 1 attendee registers
>>>> Then the goal should be 1% achieved
>>>> Scenario: one registration less than the goal shows as 99%
>>>> Given a goal of 200 registrations
>>>> When 199 attendees register
>>>> Then the goal should be 99% achieved
>>>> Notice that Given part is exactly the same for both scenarios.  
>>>> Does it
>>>> possible to DRY up it a little bit by putting Given up to right  
>>>> after
>>>> Story part? Or it is just too crazy?
>>> Depends on who the audience is. If you're using plain text w/  
>>> customers,
>>> yes it's crazy. The whole point is to keep things non-programatic.
>>> If you're a developer, then write the stuff in pure Ruby and you  
>>> have
>>> plenty of language-tools to DRY things up to your heart's content.
>> Or leave the plain-text MOIST* and rejoice in the fact that the  
>> step can be
>> shared and therefor DRY things up.
>> *MOIST = More Obvious In Simple Text
>> --
>> Rick DeNatale
>> My blog on Ruby
>> http://talklikeaduck.denhaven2.com/
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list