[rspec-users] Cucumber Scenario syntax

Jonathan Linowes jonathan at parkerhill.com
Thu Sep 18 02:10:31 EDT 2008


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



More information about the rspec-users mailing list