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@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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
