Last night, I gave a presentation to the DC Ruby Users Group (http://dcrug.org ) on Plain Text Stories with Ruby. I spoke on both RSpec Plain Text Stories, which I have used, and Cucumber which I started to dig into a couple of nights ago. You can see the presentation here (http://evan.tiggerpalace.com/2008/09/11/plain-text-stories-at-dcrug/ ) if that floats your boat. You may also note in the linked blog entry that the general consensus at DCRUG (and my own feeling as well) is that Cucumber''s scenario syntax perhaps assumes undue technical ignorance on the part of the scenario author(s). It seems odd to me (and several DCRUGgers) that the hooks into the Scenario steps/substitution points are not apparent by reading the Scenario plain text. That is, you have to read the Scenario step implementations to figure out where the hooks are in the Scenario plain text. This seems somewhat wrong-headed. As one DCRUGger said to me last night, we should at least assume that Scenario authors can handle a basic Excel spreadsheet. That is, that the Scenario could contain the FIT table column headers so that the Scenarios serve as templates that are specialized by rows in the FIT table. This seems more natural as the substitutions become far clearer just by looking at the plain text. Disclaimer: My exposure to FIT is limited to a quick read of Ward Cunningham''s page on FIT and Cucumber. Evan
I agree. Seems much more useful to me to think of the first one as being a template that stuff gets plugged in to. Pat
On Fri, Sep 12, 2008 at 10:35 AM, Evan David Light <lists at tiggerpalace.com> wrote:> Last night, I gave a presentation to the DC Ruby Users Group > (http://dcrug.org) on Plain Text Stories with Ruby. I spoke on both RSpec > Plain Text Stories, which I have used, and Cucumber which I started to dig > into a couple of nights ago. You can see the presentation here > (http://evan.tiggerpalace.com/2008/09/11/plain-text-stories-at-dcrug/) if > that floats your boat. > > You may also note in the linked blog entry that the general consensus at > DCRUG (and my own feeling as well) is that Cucumber''s scenario syntax > perhaps assumes undue technical ignorance on the part of the scenario > author(s). > > It seems odd to me (and several DCRUGgers) that the hooks into the Scenario > steps/substitution points are not apparent by reading the Scenario plain > text. That is, you have to read the Scenario step implementations to figure > out where the hooks are in the Scenario plain text. > > This seems somewhat wrong-headed. As one DCRUGger said to me last night, we > should at least assume that Scenario authors can handle a basic Excel > spreadsheet. That is, that the Scenario could contain the FIT table column > headers so that the Scenarios serve as templates that are specialized by > rows in the FIT table. This seems more natural as the substitutions become > far clearer just by looking at the plain text. > > Disclaimer: My exposure to FIT is limited to a quick read of Ward > Cunningham''s page on FIT and Cucumber.I commented on your blog. Cheers, David> > Evan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Fri, Sep 12, 2008 at 10:35 AM, Evan David Light <lists at tiggerpalace.com> wrote:> Last night, I gave a presentation to the DC Ruby Users Group > (http://dcrug.org) on Plain Text Stories with Ruby. I spoke on both RSpec > Plain Text Stories, which I have used, and Cucumber which I started to dig > into a couple of nights ago. You can see the presentation here > (http://evan.tiggerpalace.com/2008/09/11/plain-text-stories-at-dcrug/) if > that floats your boat. > > You may also note in the linked blog entry that the general consensus at > DCRUG (and my own feeling as well) is that Cucumber''s scenario syntax > perhaps assumes undue technical ignorance on the part of the scenario > author(s). > > It seems odd to me (and several DCRUGgers) that the hooks into the Scenario > steps/substitution points are not apparent by reading the Scenario plain > text. That is, you have to read the Scenario step implementations to figure > out where the hooks are in the Scenario plain text. > > This seems somewhat wrong-headed. As one DCRUGger said to me last night, we > should at least assume that Scenario authors can handle a basic Excel > spreadsheet. That is, that the Scenario could contain the FIT table column > headers so that the Scenarios serve as templates that are specialized by > rows in the FIT table. This seems more natural as the substitutions become > far clearer just by looking at the plain text.Please keep in mind that this is an *additional* way to do things - you can still write your steps exactly as you do in Story Runner, using regexps. Cheers, David> > Disclaimer: My exposure to FIT is limited to a quick read of Ward > Cunningham''s page on FIT and Cucumber. > > Evan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Sep 12, 2008, at 11:51 AM, David Chelimsky wrote:> Please keep in mind that this is an *additional* way to do things - > you can still write your steps exactly as you do in Story Runner, > using regexps.Ah, good point. I missed that nuance in your comment on my blog. Perhaps the presence of the FIT table should alter Cucumber''s behavior WRT Scenario? This could allow the original Story Runner syntax to hold. However, it would also allow, in the presence of a FIT table, for a Scenario to serve as a template. WDYT? (had to consider that acronym when I first saw it today). Evan
On Fri, Sep 12, 2008 at 11:04 AM, Evan David Light <lists at tiggerpalace.com> wrote:> > On Sep 12, 2008, at 11:51 AM, David Chelimsky wrote: > >> Please keep in mind that this is an *additional* way to do things - >> you can still write your steps exactly as you do in Story Runner, >> using regexps. > > Ah, good point. I missed that nuance in your comment on my blog. > > Perhaps the presence of the FIT table should alter Cucumber''s behavior WRT > Scenario? This could allow the original Story Runner syntax to hold. > However, it would also allow, in the presence of a FIT table, for a > Scenario to serve as a template.What you''re proposing might look this: Scenario: division Given a numerator And a denominator Then the calculator should provide a quotient |numerator|denominator|quotient| This will put some constraints on the phrasing that might be a good thing, might not. What if we just allowed free text in there that was not at all bound to the table: Examples: division When you divide a numerator by a denominator, the calculator should provide the quotient. |numerator|denominator|quotient| WDYTAT?> > WDYT? (had to consider that acronym when I first saw it today). > > Evan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Sep 12, 2008, at 11:50 AM, David Chelimsky wrote:> I commented on your blog.Yup, I know. I know very well who you are, David. ;-) I''ve seen you speak a few times and even chatted with you briefly outside RailsConf ''08 about this crazy idea that I had to redo RSpec Plain Text Stories in Treetop. Then you told me that Aslak already did it. ;-) Evan
On Sep 12, 2008, at 12:14 PM, David Chelimsky wrote:> What you''re proposing might look this: > > Scenario: division > Given a numerator > And a denominator > Then the calculator should provide a quotient > > |numerator|denominator|quotient| > > This will put some constraints on the phrasing that might be a good > thing, might not. >I agree that my proposal is not necessarily the answer.> What if we just allowed free text in there that was not at all bound > to the table: > > Examples: division > When you divide a numerator by a denominator, > the calculator should provide the quotient. > > |numerator|denominator|quotient| > > WDYTAT?I believe that binding the table to the phrasing would be immensely useful and perhaps even crucial to Scenario authors. Also, couldn''t your second example also support binding to the table headers? Evan
On Fri, Sep 12, 2008 at 11:16 AM, Evan David Light <lists at tiggerpalace.com> wrote:> > On Sep 12, 2008, at 11:50 AM, David Chelimsky wrote: > >> I commented on your blog. > > > Yup, I know. I know very well who you are, David. ;-) I''ve seen you speak > a few times and even chatted with you briefly outside RailsConf ''08 about > this crazy idea that I had to redo RSpec Plain Text Stories in Treetop. > Then you told me that Aslak already did it. ;-)I remember you well from RailsConf and associated Werewolf games. I was really responding to try to keep the conversation in one place :) Cheers, David
On Sep 12, 2008, at 12:19 PM, David Chelimsky wrote:> On Fri, Sep 12, 2008 at 11:16 AM, Evan David Light > <lists at tiggerpalace.com> wrote: >> >> On Sep 12, 2008, at 11:50 AM, David Chelimsky wrote: >> >>> I commented on your blog. >> >> >> Yup, I know. I know very well who you are, David. ;-) I''ve seen >> you speak >> a few times and even chatted with you briefly outside RailsConf ''08 >> about >> this crazy idea that I had to redo RSpec Plain Text Stories in >> Treetop. >> Then you told me that Aslak already did it. ;-) > > I remember you well from RailsConf and associated Werewolf gamesHrm. You witnessed one of my crappier Werewolf games. Feel free to erase that memory at your convenience. ;-)> . I > was really responding to try to keep the conversation in one place :)Roger roger. I''d rather have it here than on my blog as well. The more, the merrier.
On Fri, Sep 12, 2008 at 11:19 AM, Evan David Light <lists at tiggerpalace.com> wrote:> > On Sep 12, 2008, at 12:14 PM, David Chelimsky wrote: > >> What you''re proposing might look this: >> >> Scenario: division >> Given a numerator >> And a denominator >> Then the calculator should provide a quotient >> >> |numerator|denominator|quotient| >> >> This will put some constraints on the phrasing that might be a good >> thing, might not. >> > > > I agree that my proposal is not necessarily the answer. > > >> What if we just allowed free text in there that was not at all bound >> to the table: >> >> Examples: division >> When you divide a numerator by a denominator, >> the calculator should provide the quotient. >> >> |numerator|denominator|quotient| >> >> WDYTAT? > > I believe that binding the table to the phrasing would be immensely > useful and perhaps even crucial to Scenario authors.Can you give an example of how this would be helpful?> Also, couldn''t your second example also support binding to the table > headers?Anything is possible :) How would you envision that working. What would trigger binding one word in a phrase to a header?
On Sep 12, 2008, at 12:26 PM, David Chelimsky wrote:>> I believe that binding the table to the phrasing would be >> immensely >> useful and perhaps even crucial to Scenario authors. > > Can you give an example of how this would be helpful? >I''ll try. Let''s define a couple of roles for, the sake of discussion. Features are written in plain text by a "business person" or "domain expert" who is not a programmer and that the Steps are implemented by a "code monkey". I believe that code monkeys could be confused by the following: Given a Widget When I supply a line of text that starts with a foo Then it should output bar |type of widget|text_input|result| |Widget2 |blech |foobar| Looking at the Scenario above, I can''t tell, by reading the Given, When, or Then lines where "widget_2", "blech", and "foobar" will be used respectively. However, if I could say: Given a type of widget When I supply a line of text that starts with my text input Then it should output the desired output |type of widget|my text input|the desired output| .... I believe that the latter is a fair bit cleaner. Again, this approach would use the FIT table headers as metadata that informs the use of the Scenario as a template for running Scenarios. To nitpick my suggestion just a tad, I wonder whether trimming the matched FIT column headers is a good idea or not; however, padding the FIT table headers with a little white space may also make them a little more readable. Evan>> Also, couldn''t your second example also support binding to >> the table >> headers? > > Anything is possible :) How would you envision that working. What > would trigger binding one word in a phrase to a header?
Evan David Light wrote:> On Sep 12, 2008, at 12:26 PM, David Chelimsky wrote: > >>> I believe that binding the table to the phrasing would be >>> immensely >>> useful and perhaps even crucial to Scenario authors. >> >> Can you give an example of how this would be helpful? >> > > I''ll try. > > Let''s define a couple of roles for, the sake of discussion. Features > are written in plain text by a "business person" or "domain expert" > who is not a programmer and that the Steps are implemented by a "code > monkey". > > I believe that code monkeys could be confused by the following: > > Given a Widget > When I supply a line of text that starts with a foo > Then it should output bar > > |type of widget|text_input|result| > |Widget2 |blech |foobar| > > Looking at the Scenario above, I can''t tell, by reading the Given, > When, or Then lines where "widget_2", "blech", and "foobar" will be > used respectively. > > However, if I could say: > > Given a type of widget > When I supply a line of text that starts with my text input > Then it should output the desired output > > |type of widget|my text input|the desired output| > .... > > I believe that the latter is a fair bit cleaner. Again, this approach > would use the FIT table headers as metadata that informs the use of > the Scenario as a template for running Scenarios. > > To nitpick my suggestion just a tad, I wonder whether trimming the > matched FIT column headers is a good idea or not; however, padding the > FIT table headers with a little white space may also make them a > little more readable. > > EvanInteresting idea. The problem I see is that the steps would have to bind:> Given a type of widget > When I supply a line of text that starts with my text input > Then it should output the desired outputGiven(''a type of widget'') do ... end But you would want values given by your FIT table. Given(/a .+/) do |widget| ... end So now you have a Scenario in plain text which is never run though it matches the Given step, unlike any other scenario not using FIT. So far in Cucumber the first scenario is executable, the following FIT values run the scenario with the different values. In terms of consistency and matching plain text to steps it feels like header matchers complicate things. I agree there is difficulty with FIT values and bindings. I find using good descriptive columns names really helps and quoting bound values in the plain text. I find this much easier to match up: Given a ''Widget'' When I supply a line of text that starts with a ''foo'' Then it should output ''bar'' But as you said it still leaves some instances where its confusing. I''m also playing with a tool I''ve written to allow business people to edit FIT values in cucumber through a web interface. I''m starting to feel that I''m happy writing plain text features/scenarios but FIT tables are the sort of thing I would really rather do through a FITness style wiki. If quotes are a pain perhaps this is something that could be combated by IDEs and a clever syntax highlighting plugin (using colour maybe)? -- Joseph Wilk http://www.joesniff.co.uk -- Posted via http://www.ruby-forum.com/.
On Sep 12, 2008, at 4:01 PM, Joseph Wilk wrote:> I agree there is difficulty with FIT values and bindings. I find using > good descriptive columns names really helpsCouldn''t agree more there.> and quoting bound values in > the plain text. I find this much easier to match up: > > Given a ''Widget'' > When I supply a line of text that starts with a ''foo'' > Then it should output ''bar'' >This is a clever hack around a current weakness in Cucumber. I really like it. However, it would sit better with me if Cucumber enforced that syntax.
On Sep 12, 2008, at 4:01 PM, Joseph Wilk wrote:> Evan David Light wrote: >> On Sep 12, 2008, at 12:26 PM, David Chelimsky wrote: >> >>>> I believe that binding the table to the phrasing would be >>>> immensely >>>> useful and perhaps even crucial to Scenario authors. >>> >>> Can you give an example of how this would be helpful? >>> >> >> I''ll try. >> >> Let''s define a couple of roles for, the sake of discussion. Features >> are written in plain text by a "business person" or "domain expert" >> who is not a programmer and that the Steps are implemented by a "code >> monkey". >> >> I believe that code monkeys could be confused by the following: >> >> Given a Widget >> When I supply a line of text that starts with a foo >> Then it should output bar >> >> |type of widget|text_input|result| >> |Widget2 |blech |foobar| >> >> Looking at the Scenario above, I can''t tell, by reading the Given, >> When, or Then lines where "widget_2", "blech", and "foobar" will be >> used respectively. >> >> However, if I could say: >> >> Given a type of widget >> When I supply a line of text that starts with my text input >> Then it should output the desired output >> >> |type of widget|my text input|the desired output| >> .... >> >> I believe that the latter is a fair bit cleaner. Again, this >> approach >> would use the FIT table headers as metadata that informs the use of >> the Scenario as a template for running Scenarios. >> >> To nitpick my suggestion just a tad, I wonder whether trimming the >> matched FIT column headers is a good idea or not; however, padding >> the >> FIT table headers with a little white space may also make them a >> little more readable. >> >> Evan > > Interesting idea. The problem I see is that the steps would have to > bind: > >> Given a type of widget >> When I supply a line of text that starts with my text input >> Then it should output the desired output > > Given(''a type of widget'') do > ... > end > > But you would want values given by your FIT table. > > Given(/a .+/) do |widget| > ... > end > > So now you have a Scenario in plain text which is never run though it > matches the Given step, unlike any other scenario not using FIT. > > So far in Cucumber the first scenario is executable, the following FIT > values run the scenario with the different values. In terms of > consistency and matching plain text to steps it feels like header > matchers complicate things. > > I agree there is difficulty with FIT values and bindings. I find using > good descriptive columns names really helps and quoting bound > values in > the plain text. I find this much easier to match up: > > Given a ''Widget'' > When I supply a line of text that starts with a ''foo'' > Then it should output ''bar'' > > But as you said it still leaves some instances where its confusing. > I''m > also playing with a tool I''ve written to allow business people to edit > FIT values in cucumber through a web interface. I''m starting to feel > that I''m happy writing plain text features/scenarios but FIT tables > are > the sort of thing I would really rather do through a FITness style > wiki. > > If quotes are a pain perhaps this is something that could be > combated by > IDEs and a clever syntax highlighting plugin (using colour maybe)? > > -- > Joseph Wilk > http://www.joesniff.co.uk > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-usersI''d be happy to see variable substitutions occur in the plain text, before they even get to the step code. For example Given a [type of widget] When I supply a line of text that starts with [my text input] Then it should output [the desired output] | type of widget | my text input | the desired output | | widget1 | foo | bar | Also then table variables can be used in multiple steps And there should be a link with text [type of widget] And an email should be generated with subject [the desired output] etc Perhaps that''s less "plain text" than you like, but it would be mighty useful :) linoj
Daniel Lucraft
2008-Sep-18 09:49 UTC
[rspec-users] Cucumber branch with a couple of patches
Hi all, We''re using Cucumber here at songkick.com and it''s working really well for us. I''ve created a branch here with some extra features that we needed: http://github.com/songkick/cucumber/commits/master Specifically, we''ve made the transactional fixtures optional in Rails (necessary for when running with Firewatir) and removed the Rails and Cucumber portions of the backtrace in errors. Feel free to make use of these changes if they can be useful. best, Dan
Hi,
Searched for this everywhere, so here goes.
I am having trouble matching multiline strings with leading whitespace
in them using the """ operator.
E.g.
Then the output should be
"""
Usage:
mygem [options] destination
Template Options:
-r, --ruby install the ruby template
--ruby-19 install the ruby-19 template
General options:
-f, --force force overwriting files, don''t ask
-s, --skip skip file if it exists
-q, --quiet runs quietly, no output
-V, --verbose Show lots of output
-v, --version Show this version
-p, --pretend dry run, show what would have happened
-x, --debug Show debugging output
-h, --help Show this help
"""
I am generating this (almost) t am I doing wrongexact output with 5
leading space before the options, but the expected string is
collapsing them down to one leading space:
Diff:
@@ -1,15 +1,14 @@
+Ok
+
Usage:
mygem [options] destination
-Template Options:
- -r, --ruby install the ruby template
- --ruby-19 install the ruby-19 template
General options:
- -f, --force force overwriting files, don''t
ask
- -s, --skip skip file if it exists
- -q, --quiet runs quietly, no output
- -V, --verbose Show lots of output
- -v, --version Show this version
- -p, --pretend dry run, show what would have happened
- -x, --debug Show debugging output
- -h, --help Show this help
+ -f, --force force overwriting files,
don''t ask
+ -s, --skip skip file if it exists
+ -q, --quiet runs quietly, no output
+ -V, --verbose Show lots of output
+ -v, --version Show this version
+ -p, --pretend dry run, show what would
have happened
+ -x, --debug Show debugging output
+ -h, --help Show this help
What am I doing wrong?
Thanks
Cheers,
Ed
Ed Howland
http://greenprogrammer.wordpress.com
http://twitter.com/ed_howland
On Sat, Feb 27, 2010 at 5:17 AM, Ed Howland <ed.howland at gmail.com> wrote:> Hi, > > Searched for this everywhere, so here goes. > > I am having trouble matching multiline strings with leading whitespace > in them using the """ operator. > >Cucumber intentionally removes all the space characters left of the leftmost triple quote. Just indent everything relative to the leftmost triple quote and you''ll be ok. Aslak> E.g. > Then the output should be > """ > Usage: > mygem [options] destination > Template Options: > -r, --ruby install the ruby template > --ruby-19 install the ruby-19 template > General options: > -f, --force force overwriting files, don''t ask > -s, --skip skip file if it exists > -q, --quiet runs quietly, no output > -V, --verbose Show lots of output > -v, --version Show this version > -p, --pretend dry run, show what would have happened > -x, --debug Show debugging output > -h, --help Show this help > """ > > I am generating this (almost) t am I doing wrongexact output with 5 > leading space before the options, but the expected string is > collapsing them down to one leading space: > Diff: > > > @@ -1,15 +1,14 @@ > +Ok > + > Usage: > mygem [options] destination > -Template Options: > - -r, --ruby install the ruby template > - --ruby-19 install the ruby-19 template > General options: > - -f, --force force overwriting files, don''t ask > - -s, --skip skip file if it exists > - -q, --quiet runs quietly, no output > - -V, --verbose Show lots of output > - -v, --version Show this version > - -p, --pretend dry run, show what would have > happened > - -x, --debug Show debugging output > - -h, --help Show this help > + -f, --force force overwriting files, don''t > ask > + -s, --skip skip file if it exists > + -q, --quiet runs quietly, no output > + -V, --verbose Show lots of output > + -v, --version Show this version > + -p, --pretend dry run, show what would > have happened > + -x, --debug Show debugging output > + -h, --help Show this help > > > What am I doing wrong? > > Thanks > > Cheers, > Ed > > Ed Howland > http://greenprogrammer.wordpress.com > http://twitter.com/ed_howland > _______________________________________________ > 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/20100227/8e95573e/attachment-0001.html>