Reputation: 2020
I want to move a multi-row scenario to a scenario outline so that the individual lines of the table can be tested as separate tests. Here's a simplified example of what I have in mind:
Scenario: This scenario loops through the lines of the table performing an assert on each line
When I do something and verify it
| name | parameter1 | parameter2 | parameter3 |
| A and 1 | A | 1 | true |
| B and 1 | B | 1 | false |
| A and 2 | A | 2 | false |
| B and 2 | B | 2 | true |
The step definition looks like this:
@When("I do something and verify it")
public void doSomethingAndVerifyIt(DataTable dataTable) {
List<Map<String, String>> keyValues = dataTable.asMaps();
for (Map<String, String> keyValue : keyValues) {
assertSomething(keyValue.get("parameter1"), keyValue.get("parameter2"), keyValue.get("parameter3"));
}
}
This works fine, but if any of the rows fails the assertion step, then the test stops at this point. I'd like to change this to using a scenario outline along these lines so that the lines can pass or fail independently of each other:
Scenario Outline: This scenario loops through the lines of the table performing an assert on each line
When I do something and verify it
Examples:
| name | parameter1 | parameter2 | parameter3 |
| A and 1 | A | 1 | true |
| B and 1 | B | 1 | false |
| A and 2 | A | 2 | false |
| B and 2 | B | 2 | true |
How do I change the step definition so that each time, one row is read by the test? I know that I could do this by adding a line under the step definition that explicitly declares each parameter by name, but in my case this would involve a huge number of parameters.
Is there a simpler way to do this along these lines:
@When("I do something and verify it")
public void doSomethingAndVerifyIt(Map<String, String> keyValue) {
assertSomething(keyValue.get("parameter1"), keyValue.get("parameter2"), keyValue.get("parameter3"));
}
Upvotes: 0
Views: 734
Reputation: 4099
See my other answer for how to use table.
A better way to improve your scenario is to convert your examples to named rules. Examples are very useful when capturing information from the business when discussing behaviour. However they are not very good when it comes to writing code. Lets explore this a bit with password login.
Say we have
password | success?
123456 | no
xb32drthcyfe | no
p@ssword1 | yes
as our examples. The problem we have here is we don't know WHY xb32drthcyfe
should fail and p@ssword1
should succeed. We can guess, but our scenario has failed to record the WHY.
Now consider
Scenario: Passwords must contain a symbol
When I register with a password without a symbol
Then I should see my password needs a symbol
Now you have a single scenario that not only documents the WHY, but allows you to challenge the WHY, and explore the WHY e.g
Scenario: Weak password that contains a symbol
Given my password is long enough has a symbol but it is really weak
When I register with my password
Then I should be registered.
Now you can present the above behaviour to your business and say, do we really want to do this.
Every example should have a unique named rule behind it. For an example to become mature enough to reside in your cukes you need to reveal this rule, give it a name and then replace the usage of the example in your cukes with scenarios exploring the rule.
Upvotes: 0
Reputation: 4099
You have to use the column headers in your step defs as params so cucumber can replace the params with values in your table e.g
Scenario Outline: eating
Given there are <start> cucumbers
When I eat <eat> cucumbers
Then I should have <left> cucumbers
Examples:
| start | eat | left |
| 12 | 5 | 7 |
| 20 | 5 | 15 |
Upvotes: 0