Forum: RSpec Cucumber Scenario syntax

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

On Fri, Sep 12, 2008 at 10:35 AM, Evan David Light
<lists@tiggerpalace.com> wrote:
> author(s).
> 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

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 10:35 AM, Evan David Light
<lists@tiggerpalace.com> wrote:
> author(s).
> 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

On Fri, Sep 12, 2008 at 11:04 AM, Evan David Light
<lists@tiggerpalace.com> wrote:
> 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?

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 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:

> 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@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 Fri, Sep 12, 2008 at 11:19 AM, Evan David Light
<lists@tiggerpalace.com> wrote:
>>  |numerator|denominator|quotient|
>> to the table:
> 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:19 PM, David Chelimsky wrote:

>> 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

Hrm.  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 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

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

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 helps

Couldn'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:

>> I'll try.
>> Then it should output bar
>> Given a type of widget
>>
>
> Given(/a .+/) do |widget|
>
> I'm
>
> --
> Joseph Wilk
> http://www.joesniff.co.uk
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


I'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

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@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