Cucumber tables

Testing RSpec
1

I cannot seem to locate any documentation on how to implement the new
table syntax otherwise I would not bother the list with this.

I wish to write something like this:

And we do have a forex rate for the following currency code and date
|code | date | rate |
|“USD”|“2009-04-01”|“0.8555”|
|“USD”|“2009-04-05”|“0.8444”|

Then /^we do have a forex (.+) for the following currency (.+) and
(.+)$/
do |rate,code,date,table|

table is a Cucumber::Ast::Table

puts rate
puts code
puts date

end

All I see from this is:
…
rate
code
date
And we do have a forex rate for the following currency code and date

features/app/models/currency_exchange_rates/step_definitions/currency_exchange_rates_steps.rb:8
| code | date | rate |
| “USD” | “2009-04-01” | “0.8555” |
| “USD” | “2009-04-05” | “0.8444” |

I only get one iteration of output and that only displays the regex
matches found in the original string.

What is happening with the rest of the data? Is the table data keyed by
the headings or is it position dependent on the matcher order? In other
words, does the data in the table have to be in the same order as the
regexp in the preceding clause. If so, then why the table headings?

2

I do not know if I am doing something wrong or not, but I am seeing
evidence that feature tables in normal scenarios do not actually do
anything.

feature statement

And we do have a forex rate for "USD" on "2009-03-31" of "0.8666"
  | "USD" | "2009-04-01" | "0.8555" |
  | "USD" | "2009-04-05" | "0.8444" |
Then the number of forex rates should be 3

step definition

Then /do have a forex rate for “([^”])" on “([^”])" of “([^”]*)"/
do |code,date,rate,table|
my_rate = CurrencyExchangeRate.new
my_rate.currency_code_base = ‘CAD’
my_rate.currency_code_quote = code
my_rate.currency_exchange_rate = rate
my_rate.currency_exchange_source = ‘features test’
my_rate.currency_exchange_type = ‘TEST’
my_rate.effective_from = date
my_rate.save!
end

Then /the number of forex rates should be (\d+)/ do |count|
CurrencyExchangeRate.count.should ==(count)
end

But, the results of this are:

And we do have a forex rate for "USD" on "2009-03-31" of "0.8666"
    # features/app/models/currency_exchange_rates/step_definitions
        /currency_exchange_rates_steps.rb:8
  | "USD" | "2009-04-01" | "0.8555" |
  | "USD" | "2009-04-05" | "0.8444" |

Then the number of forex rates should be 3
    # features/app/models/currency_exchange_rates/step_definitions
        /currency_exchange_rates_steps.rb:81
  expected: "3",
       got: 1 (using ==)
  Diff:
  @@ -1,2 +1,2 @@
  -3
  +1
3

On Fri, May 15, 2009 at 11:35 AM, James B. [email protected]
wrote:

Then /^we do have a forex (.+) for the following currency (.+) and
rate
I only get one iteration of output and that only displays the regex
matches found in the original string.

What is happening with the rest of the data? Is the table data keyed by
the headings or is it position dependent on the matcher order? In other
words, does the data in the table have to be in the same order as the
regexp in the preceding clause. If so, then why the table headings?

They’re actually unrelated. Most of my table matchers have no other
regex
in the expression

You’re not seeing anything else with the table data because you’re not
doing
anything with the table data.

Given /the following data rates/ do |table|
table.hashes.each do |row|
puts row[“code”]
end
end

–

4

Aslak Hellesøy wrote:

http://wiki.github.com/aslakhellesoy/cucumber/scenario-outlines

Please let us know what’s missing or unclear about that.

That documentation is for scenario outlines. I had gathered that one
could also simply use tables with regular scenarios where the table
values replaced the rexep in the preceding statement. At one point I am
sure that this is what I was doing, although the table followed a
complete scenario. However, I have not used tables for the last couple
of months and am somewhat perplexed with respect to the changes.

5

I cannot seem to locate any documentation on how to implement the new
table syntax otherwise I would not bother the list with this.

I’m not sure what you mean by “new” table syntax. The syntax for
tables hasn’t really changed since it was introduced.

I wish to write something like this:

And we do have a forex rate for the following currency code and date
|code | date | rate |
|“USD”|“2009-04-01”|“0.8555”|
|“USD”|“2009-04-05”|“0.8444”|

Why are you quoting the cell values?

…
rate
code
date

Which makes sense - these are the values of the 3 groups in your regexp.

What is happening with the rest of the data? Is the table data keyed by
the headings or is it position dependent on the matcher order? In other
words, does the data in the table have to be in the same order as the
regexp in the preceding clause. If so, then why the table headings?

Doc:

http://wiki.github.com/aslakhellesoy/cucumber/scenario-outlines

Please let us know what’s missing or unclear about that.

Aslak

6

sure that this is what I was doing, although the table followed a
complete scenario. However, I have not used tables for the last couple
of months and am somewhat perplexed with respect to the changes.

What are these changes you are talking about?? The only thing that
changed was:

  • the “More Examples” keyword was renamed to “Examples”.
  • “Examples” can only be used under “Scenario Outline”, not “Scenario”.

These are minor changes that haven’t really changed anything
fundamentally. You can find the documentation for multiline step
arguments here:

http://wiki.github.com/aslakhellesoy/cucumber/multiline-step-arguments

Aslak

7

Chris F. wrote:

They’re actually unrelated. Most of my table matchers have no other
regex in the expression

You’re not seeing anything else with the table data because you’re not
doing
anything with the table data.

Given /the following data rates/ do |table|
table.hashes.each do |row|
puts row[“code”]
end
end

Thank you very much. Could you give me the rdoc reference for this
construct. This is exactly the sort of thing I was looking for and
could not find.

8

Aslak Hellesøy wrote:

sure that this is what I was doing, although the table followed a
complete scenario. �However, I have not used tables for the last couple
of months and am somewhat perplexed with respect to the changes.

What are these changes you are talking about?? The only thing that
changed was:

  • the “More Examples” keyword was renamed to “Examples”.
  • “Examples” can only be used under “Scenario Outline”, not “Scenario”.

These are minor changes that haven’t really changed anything
fundamentally. You can find the documentation for multiline step
arguments here:

Yes, I followed that part. The part I did not comprehend was using
multiline step arguments, which are more commonly referred to as tables
as well insofar as I can see. I was looking for “tables” in the
documentation, not “multiline step arguments”, which conveys to me a
completely different meaning than the one evidently intended.

Nonetheless, Mr. Flipse’s post has put me right and I am on to the next
bit of confusion.

9 
table.hashes.each do |row|
   puts row["code"]
end

end

Thank you very much. Could you give me the rdoc reference for this
construct. This is exactly the sort of thing I was looking for and
could not find.

I just added a wiki page for this:

The table RDoc is here:
http://localhost:8808/doc_root/cucumber-0.3.5/rdoc/Cucumber/Ast/Table.html

Aslak

10

These are minor changes that haven’t really changed anything
fundamentally. You can find the documentation for multiline step
arguments here:

Yes, I followed that part. Â The part I did not comprehend was using
multiline step arguments, which are more commonly referred to as tables
as well insofar as I can see. Â I was looking for “tables” in the
documentation, not “multiline step arguments”, which conveys to me a
completely different meaning than the one evidently intended.

I’m aware that the two different kind of tables can be confusing, so
I’ll try to always refer to them as:

“multiline argument tables” or maybe “step argument tables” or even
“argument tables”

and

“scenario outline tables” or “example tables”

Which terms do you think we should adopt and where in the wiki should
this be emphasized more clearly?

Aslak

11

As far as the wiki goes then I suggest a general entry with the heading
“Tables”. This page should contain a brief description of each type of
table explaining where each is encountered together with links to their
respective example. Nothing overly elaborate, just a single place to

Good idea

note that their is more than one type and that their employment and
syntax differs somewhat.

Their syntax is identical, but they have different semantics.

Cucumber is a marvellous tool, but the rate of enhancement ofttimes
leaves me behind for a bit. However, I far prefer having to sprint now
and then rather than dragging a moribund tool around behind me, wishing
that it had this or did that.

Hehe. Thanks. Hopefully there won’t be any major changes to the
language from now on…
Hopefully :wink:

Aslak

12

Aslak Hellesøy wrote:

Which terms do you think we should adopt and where in the wiki should
this be emphasized more clearly?

Aslak

The best suggestion that I can come up with is: Outline Tables for
Scenario Outlines and Inline Tables for regular scenarios.

As far as the wiki goes then I suggest a general entry with the heading
“Tables”. This page should contain a brief description of each type of
table explaining where each is encountered together with links to their
respective example. Nothing overly elaborate, just a single place to
note that their is more than one type and that their employment and
syntax differs somewhat.

Cucumber is a marvellous tool, but the rate of enhancement ofttimes
leaves me behind for a bit. However, I far prefer having to sprint now
and then rather than dragging a moribund tool around behind me, wishing
that it had this or did that.