[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