charlierudolph
commented
6 years ago Since javascript does not have types, I think that makes this much harder to implement in a reliable way. We currently only know the number of arguments the function takes and not what type each argument is. We could get the function argument names (via something like: https://github.com/goatslacker/get-parameter-names, though based on the code I anticipate that may not work with de-structured arguments) but then we would be forcing the user to use specific names for things like data tables and callbacks when using the callback interface.
In terms of optional data tables, I have typically ended step texts with : if it has a table / doc string.
/^I create a user$/ // (no colon, uses defaults)
/^I create a user:$/ // (with colon and has a table)I think the first having a colon appears a typo to me as nothing comes after it. Also I think the second may read better as: I create a user with the following fields:.
osmolyar
lock[bot]
Ref. https://github.com/webdriverio/wdio-cucumber-framework/issues/109
Is there a reason why step matching is performed only on the regex of the step and not the number or type of parameters?
This precludes overloading a step definition to require a data table input vs. not require any input parameters (e.g., perform the step based on data defaults defined elsewhere in the context).
The above functionality is available in SpecFlow and is highly useful for differentiating steps using defaults vs. ones requiring input without having to define different text for the steps.
Even if one is able to handle the presence or absence of a table parameter within the step definition (by checking whether typeof table is 'function' or an object, for instance), the test still errors out saying "function uses multiple asynchronous interfaces: callback and promise" since the step expects a table but the feature file doesn't have one (https://github.com/cucumber/cucumber-js/issues/872).
So it appears the only workaround is to define differently worded steps for default and non-default input, which is nonstandard for functions in most major programming languages.