I am working with the BDD framework, and I have very large scenarios with many examples-CodePudding

I am working with the BDD framework, and I have very large scenarios with many examples (test data). How can i minimise these examples and scenarios to make them more maintainable?

or how can i read my examples(test data) from excel sheet instead of implementing all the examples inside the feature file . is this good solution?

What I'm currently doing is implementing all of the examples in my Feature File, despite the fact that in some scenarios, I have more than 20 columns Example , which are extremely difficult to change and maintain on a regular basis.

something like this .

Scenario Outline: success renewal MI bundle 

 Given msisdn "<msisdn>" is active on service class id "<serviceClass>"
 And msisdn "<msisdn>" has balance equal "<miFees>"
 And delete all offers from msisdn "<msisdn>"
 And msisdn "<msisdn>" has bundle id "<Offer1>" opted in  with offer2"<offer2>"
 And msisdn "<msisdn>" has usage  "<usage1>" with usage  "<usage2>" and usage threshold id "<usageThresholdId>"
 And dedicated id "<dedicted1>" updated for msisdn "<msisdn>" with dedicated value "<dedicated2>"
 And msisdn "<msisdn>" has balance equal "<balance>"
 And msisdn "<msisdn>" has offer id "<offer1>" with validity duration "<validityToday>"
 And msisdn "<msisdn>" has dummy offer
 When pamID "<pam>" runs for msisdn "<msisdn>" while having "<offer1>"
 Then validate msisdn "<msisdn>" has offer with offer id "<offer1>"
 And validate msisdn "<msisdn>" has offer id "<offer1>" with validity duration "<validityDuration>"
 And validate msisdn "<msisdn>" has offer with offer id "<offer2>"
 And validate msisdn "<msisdn>" has offer id "<offer3>" with validity duration "<validityDuration>"
 And validate that msisdn "<msisdn>" balance should be equal                  "<balanceAfter>"
 And validate that msisdn "<msisdn>" has product id "<product1>" and quota name "<quotaName>" and max quota should be "<maxQuota>"
 And validate that msisdn "<msisdn>" has product id "<offer3>" and quota name "<rolloverQuotaName>" and max quota should be "<rolloverQuota>"
 And  validate msisdn "<msisdn>" has dedicated id "<dedicated1>" with dedicated value "<dedicatedValue1>"
 And validate msisdn "<msisdn>" has dedicated id "<dedicated2>" with dedicated value "<dedicatedValue2>"

 Examples:

   | msisdn | serviceClass | balance | validityDuration | offer1 | offer2 | usage1 | usage2 | usageThresholdId | validityToday | pam | offer3 | balanceAfter | product1 | quotaName | maxQuota | rolloverQuota | rolloverQuotaName | dedicated1 | dedicatedValue1 | dedicated2 | dedicatedValue2 |
   | xx     | xxx          | xx      | xx               | xx     |        | xx     | xx     | xx               | xx            | xx  | xxx    | xxxx         | xxxxx    | x         | xx       | xxx           | xx                | xx         | xxx             | xx         | xx              |

CodePudding user response：

So you're using a BDD Framework. And one of the aims of BDD is that the specifications can be understood by domain experts.

This means that feature files are relatively self contained. They should contain everything someone needs to understand a feature. Reading data from Excel would break that containment. So you won't find much support for that.

Now you could rewrite your scenario to not need these identifiers. But I can't quite work out what you're actually testing to give you a good example. Try writing down in plain words what you are testing.

Now perhaps you have already done that in the past. And I would have to guess about the circumstances that got you to write a scenario like this. But you may have to go back and fix those problems instead of working around them.

Either that or change to a more data driven framework. Spock comes to mind.

CodePudding user response：

Cucumber is best used to describe WHAT you are doing and WHY its important. It's much worse at detailing HOW something is done. To make you scenarios better you need to push the how down. To do this I would suggest the following

Avoid scenario outlines and example groups, do one test at a time
Use the power of language to abstract so instead of

Scenario: Login
  Given I am registered
  When I view the login page
  And I fill in my email with [email protected]
  And I fill in my password with password
  And I click the login button

You have

Scenario: Login
  Given I am registered
  When I login
  Then I should be logged in

To do all the details of who I am, how I login, how I registered etc. have been pushed down into step definitions (and ideally even lower into helper methods for those step definitions).

This will be a big job, because you have to really understand WHAT you are doing and WHY its important, and probably have to ask some difficult questions to get that understanding.