I am running into this situation:
Feature 1
Scenario A
...
Then we should have currency exchange rates for "USD" on file
And we should ...
Feature 2
Scenario D
...
Then we should have currency exchange rates for "USD" on file
| code|
|"EUR"|
|"JPY"|
|"KRW"|
|"MXN"|
And we should not ...
This arrangement presently gives a cucumber error because the step
definition that matches will either have one argument too many or one
too few. However, from a user point of view it strikes me that this
situation should not be an error at all.
My reasoning is this. The features statement as given is completely
logical, straight-forward and applicable in either situation. Having a
requirement to create separate invocations for exactly the same test,
depending only upon whether one wishes to do it once or several times,
strikes me as bending the situation to the limitations of the
implementation rather than elaborating the implementation to handle the
situation.
On the other hand, as this may be quite involved to solve I am not
saying what I suggest MUST be the behavior, only that it seems to me
that it should be.
I seem to recall that when I first used cucumber in December last, that
one could either provide additional examples to a matcher in a scenario
or not. In either case the matcher would work. I think that this
behaviour, if at all possible, might be more natural than requiring two
separate matchers that exist only to match to different patterns.
What do you all think?
--
Posted via http://www.ruby-forum.com/.
> I am running into this situation: > > Feature 1 > > ?Scenario A > ? ?... > ? ?Then we should have currency exchange rates for "USD" on file > ? ? ?And we should ... > > > Feature 2 > > ?Scenario D > ? ?... > ? ?Then we should have currency exchange rates for "USD" on file > ? ? ? ?| code| > ? ? ? ?|"EUR"| > ? ? ? ?|"JPY"| > ? ? ? ?|"KRW"| > ? ? ? ?|"MXN"| > ? ? ?And we should not ... > > This arrangement presently gives a cucumber error because the step > definition that matches will either have one argument too many or one > too few. ?However, from a user point of view it strikes me that this > situation should not be an error at all. > > My reasoning is this. ?The features statement as given is completely > logical, straight-forward and applicable in either situation.A common way to express step definitions that take multiline arguments is to explicitly refer to the multiline argument in the step text. For example: Then I should have the following shoes: |size|model| |43 |Adidas Oslo| |41 |Nike Racer| If you don''t do this, the multiline argument is "dangling". Steps that take multiline arguments should be formulated in such a way that removing the multiline argument makes the sentence nonsensical. This is not the case for your example. Remove the table and the sentence still makes sense. That''s very confusing. In fact, sticking a table onto that sentence makes no sense at all to me. I have to guess how that table is related to the sentence above it. Be explicit, and you''ll save yourself a lot of headache. In your case I would do this: Then we should have currency exchange rates for "USD" on file Then we should have currency exchange rates for "USD" on file with the following codes: | code| |"EUR"| |"JPY"| |"KRW"| |"MXN"| Aslak> Having a > requirement to create separate invocations for exactly the same test, > depending only upon whether one wishes to do it once or several times, > strikes me as bending the situation to the limitations of the > implementation rather than elaborating the implementation to handle the > situation. > > On the other hand, as this may be quite involved to solve I am not > saying what I suggest MUST be the behavior, only that it seems to me > that it should be. > > I seem to recall that when I first used cucumber in December last, that > one could either provide additional examples to a matcher in a scenario > or not. ?In either case the matcher would work. ?I think that this > behaviour, if at all possible, might be more natural than requiring two > separate matchers that exist only to match to different patterns. > > What do you all think? > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Aslak Helles?y wrote:> > If you don''t do this, the multiline argument is "dangling". Steps that > take multiline arguments should be formulated in such a way that > removing the multiline argument makes the sentence nonsensical.Yes, I understood that. And I also realized that the solution is to have two separately phrased matcher clauses. However, this approach does strike me as incongruous with cucumber''s philosophy of reading naturally. Consider this situation. Iteration 1 to 5 Then we should have currency exchange rates for "USD" on file Iteration 6 Then we should have currency exchange rates for "USD" on file with the following codes | code| |"EUR"| |"JPY"| Now, besides begin awkwardly worded, "rates for "USD" on file with the following codes" (which admittedly could be repaired with some thought), this requires that an additional matcher be provided in the step definition file. Further, the similarity of phrasing is an invitation to a matcher collision. I rather suspect that in these cases this is what will end up in the feature files on most occasions: Then we should have currency exchange rates for "USD" on file Then we should have currency exchange rates for "EUR" on file Then we should have currency exchange rates for "JPY" on file This requires far less work as the matcher already exists and one need only replace six characters after a couple of cut and pastes. Presently, the table method works best, I think, when it is employed from the outset. However, when things are elaborated after the initial matchers are written then it seems more work than it is worth to duplicate existing matchers just to cut down somewhat on boilerplate in the feature files. If, instead, one could just add a table under an existing step matcher then this would be more in keeping with what cucumber does so well elsewhere, extend features and scenarios naturally and effortlessly. Then we should have currency exchange rates for "USD" on file | code| |"EUR"| |"JPY"| This is more user friendly because it creates far less of an intellectual load (having to devise a new wording for an existing phrase and implementing same as a special case) than simply extending the existing structure. -- Posted via http://www.ruby-forum.com/.
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?
--
Posted via http://www.ruby-forum.com/.
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
--
Posted via http://www.ruby-forum.com/.
> 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?> 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 > dateWhich makes sense - these are the values of the 3 groups in your regexp.> ? ?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?Doc: http://wiki.github.com/aslakhellesoy/cucumber/scenario-outlines Please let us know what''s missing or unclear about that. Aslak> -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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. -- Posted via http://www.ruby-forum.com/.
Chris Flipse 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. -- Posted via http://www.ruby-forum.com/.
> 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.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> > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
> Chris Flipse 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. >I just added a wiki page for this: http://github.com/aslakhellesoy/cucumber/wikis/rdoc The table RDoc is here: http://localhost:8808/doc_root/cucumber-0.3.5/rdoc/Cucumber/Ast/Table.html Aslak> -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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. -- Posted via http://www.ruby-forum.com/.
> 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. >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> Nonetheless, Mr. Flipse''s post has put me right and I am on to the next > bit of confusion. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Aslak Helles?y wrote:> > Which terms do you think we should adopt and where in the wiki should > this be emphasized more clearly? > > AslakThe 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. -- Posted via http://www.ruby-forum.com/.
> 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 toGood 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 ;-) Aslak> -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users