[rspec-users] DRY up story

Michael Latta lattam at mac.com
Fri Sep 26 20:41:58 EDT 2008


Ticket created http://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/20-ability-to-write-steps-in-scenario-language

Michael

On Sep 26, 2008, at 5:20 PM, Michael Latta wrote:

> Using a "macros" directory rather than explicit dependencies (as is  
> now true for steps) is fine.  Unless you have a ton of macros it  
> should not be too bad performance wise.  And, it prevents duplicate  
> steps from being used in different parts of a large spec unknowingly.
>
> The most likely use case for us is to decompose top level steps into  
> more detail.  The way I would use it is Given decomposes to Givens,  
> and Then to Thens, but When can decompose into anything.  That way  
> the preconditions on the whole sequence are only preconditions, and  
> the post conditions are only post conditions, but the sequence can  
> contain both pre and post conditions.  Each step of a sequence can  
> have its own pre/post conditions.  When viewing the results I would  
> normally not care to see the decompositions.  But, in the case where  
> the decomposition is for UI details the UI designers would want to  
> see the details, while most other reviewers would not.
>
> I think I will submit a new ticket with what you suggest and what we  
> need from it.
>
> Michael
>
>
>
>
> On Sep 26, 2008, at 3:57 PM, David Chelimsky wrote:
>
>> On Fri, Sep 26, 2008 at 1:48 PM, Michael Latta <lattam at mac.com>  
>> wrote:
>>> 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
>>> response.
>>> 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?
>>
>> That ticket (http://rspec.lighthouseapp.com/projects/16211/tickets/3)
>> is fine. The thing that Aslak is already planning on doesn't really
>> address aggregating steps written in "scenario language".
>>
>>>
>>> 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?
>>
>> I'm not comfortable with the idea of stripping out the Thens or  
>> adding
>> constructs like Require to features. Dependencies are a code concept
>> and I think that stating dependencies in a feature would be more
>> confusing that clarifying.
>>
>> I do appreciate the goal, however, of being able to express "macros"
>> in "scenario" language. What I'd propose is that we add a macros
>> directory in which we'd have macro definition files that are just  
>> like
>> the ruby step definition files. So while you could define such a  
>> macro
>> in a ruby file like this (once Aslak implements it):
>>
>> Given "I am logged in as admin" do
>> Given "I am registered as admin, David, secret"
>> When "I log in with David, secret"
>> end
>>
>> ... you'd also be able to do it in a macro file like this (macro is
>> just a suggestion, feel free to counter):
>>
>> Macros:
>> Given: I am logged in as admin
>>   Given I am registered as admin, David, secret
>>   When I log in with David, secret
>>
>> WDYT about that? Now you could use ruby or "scenario language" to  
>> say:
>>
>> Scenario: admin can manage content
>> Given I am logged in as admin
>> Then I should see I should see a link to "Manage Content"
>>
>> Although, now that I see this, I don't like the fact that the Given
>> includes a When (an action). I think I'd rather see this expressed
>> this way:
>>
>> Macros:
>> When: I log in as admin
>>   Given I am registered as admin, David, secret
>>   When I log in with David, secret
>>
>> Scenario: admin can manage content
>> When I log in as admin
>> Then I should see I should see a link to "Manage Content"
>>
>> Then the question becomes whether the output should "explode" the
>> macro for the reader. I think it would be useful sometimes, and
>> detrimental other times.
>>
>> I guess, in the end, I might never use this feature myself, even if  
>> it
>> was added. I find the currently available tools much simpler.
>>
>> Any other thoughts on this?
>>
>> David
>>
>>
>>>
>>> Michael
>>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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