Details
-
Type: Improvement
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Core
-
Labels:None
-
Number of attachments :
Description
Instead of using a special construct for parametrised scenarios the same mechanism could be re-used if the parametrisation work as a kind of macro, ie before the step is parsed. For example:
Given my color mixing application
When selecting color $
And selecting color ${color2}
Then the resulting color should be ${result}
Examples:
|color1|color2|result|
|red|green|yellow|
|blue|green|cyan|
In this case I would implement the following in Java:
@Given("my color mixing application")
public void initApplication() {...}
@When("selecting color $color")
public void selectColor(String color) {...}
@Then("the resulting color should be $result")
public void checkResult(String result) {...}
The point here is that I want only one @When alias which both works with and without parametrisation.
Another benefit of this would be the possibility to parametrise which step is executed and not only the parameters. Altough I'm not sure that this is a good idea, it is certainly powerful. For example:
Given my color mixing application
When ${operation1} color ${color1}
And $
{operation2}color $
{color2}Then the resulting color should be $
{result}Examples:
operation1 | operation2 | color1 | color2 | result |
selecting | adding | red | green | yellow |
selecting | selecting | blue | green | cyan |
@When("adding color $color")
public void addColor(String color)
(Using the ant-style ${} is just an idea to keep compability with the old behaviour, but instead this new behaviour could replace the old one with <> for parameters)