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? Yi
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.> > > Yi > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080624/e553a291/attachment.html>
On Jun 24, 2008, at 4: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 Textw00t! Got one for CLEAR?> > > -- > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080624/8cd28763/attachment.html>
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. 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080925/d8b7c424/attachment.html>
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 >
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? 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? 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
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 >
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
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