Evan David L. wrote:
On Sep 12, 2008, at 12:26 PM, David C. 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 W.
http://www.joesniff.co.uk