1
votes

How to I pass multiple parameters using feature.

I am aware of usage of "Examples:" concept but it's making feature file more complicated and unreadable in some manner

Example:

Scenario Outline: To verify that default value for some timeout when invalid/remove is set for some timeout parameter

When <parameterA> is <action> with <parameterB> for <someOtherParameterPair> in <fileName>
Then <parameterA> is updated with value <parameterB> for <someOtherParameterPair> in <fileName> as per defined <action>
Examples:
|parameterA  |parameterB  |action|someOtherParameterPair|fileNameWithSectionName|
|oneParameter|twoParameter|update|key:Value             |abc.config:appSettings |
|oneParameter|twoParameter|delete|key:Value             |def.config:appSettings |

Here, I have around 7 parameters which are coming from testcase(which I have tried to accomodated in 5 parameters due to limitation)

I would be splitting "someOtherParameterPair" and "fileNameWithSectionName" into two using split in step definition file. So in total I have around 7 parameters which will be used in Test Case.

But I am not sure whether accepting such huge number of parameters from Given/When/Then statements are feasible. It's also making my test case unreadable.

In above scenario, I am trying to modify some parameters(which I am passing from feature file so that my When/Then statements could modify) present in *.config file present at certain location.

After which I need to execute the testcase.

In the same manner, I have other(most of them) cases as well in my test suite.

Please help me is BDD right approach. Is BDD going to create some issues in maintenance as I am seeing lots of things (almost everything from) feature file.

1

1 Answers

0
votes

The answer is don't write your features like this. Instead of using your feature to describe how you are testing something, use it to explain what you are testing and why you are testing it

Generally this means you don't need to use examples, and you certainly never need to use complicated examples like you've got. You can always push the usage of examples down to a lower level e.g. the step definitions.

In this case it looks like you should be writing a unit test. There is nothing of business value described in this scenario.

BDD is about describing behaviour and using that to drive development. You can't use it to test things after they have been written!!