can we have multiple examples fro same scenario outline

[Vino Maddy]

can we have multiple examples fro same scenario outline 

[Thomas Sundberg]

On 4 July 2016 at 17:28, Vino Maddy <vinom...@gmail.com> wrote:
> can we have multiple examples fro same scenario outline
>

As in two different examples?

Please share an example of what you mean and explain what you hope to
accomplish by doing so.

/Thomas

--
Thomas Sundberg
M. Sc. in Computer Science

Mobile: +46 70 767 33 15
Blog: http://thomassundberg.wordpress.com/
Twitter: @thomassundberg

Better software through faster feedback

Interested in a BDD Kickstart in Stockholm?
https://cucumber.io/events/bdd-kickstart-stockholm-16

[Vinoth Kannan]

Currently I don't have any such scenario.
I am trying to show a demo to my colleagues on cucumber and if there is option for that I would add that to my demo

Thanks

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paolo Ambrosio]

You can have multiple Example blocks for the same Scenario Outline,
and tags applied to each of them will end up tagging the Scenarios
produced from those examples.

These are two valid test cases for the Gherkin parser that might be
useful to you:

https://github.com/cucumber/gherkin/blob/master/testdata/good/several_examples.feature
https://github.com/cucumber/gherkin/blob/master/testdata/good/example_tokens_everywhere.feature

[Simone]

Here is an example from the cucumber docs:

https://github.com/cucumber/cucumber/wiki/Scenario-Outlines

Something from the Cucumber Book that I found useful was the explanation on how to use multiple tables of examples beneath a single scenario outline. This can be a way to group types of examples together to make each example a clearer encapsulation of a rule. 

Here's an excerpt from that section (p.74-75):

"You’ll normally be using a scenario outline and examples table to help specify the implementation of a business rule. Remember to include a plain-language description of the underlying rule that the examples are supposed to illustrate! It’s amazing how often people forget to do this.

For example, look at this feature: 

Feature: Account Creation

Scenario Outline: Password validation
Given I try to create an account with password "<Password>" 

Then I should see that the password is <Valid or Invalid>

Examples:

  | Password | Valid or Invalid |

  | abc           | invalid               |

  | ab1           | invalid               |

  | abc1         | invalid               |

  | abcd         | valid                  |

  | abcd1       | valid                  |

If you have to implement the code to make this feature pass, can you tell what the underlying rule is?

Not very easily. So, let’s modify the feature to make it more self-explanatory, like this:

Feature: Account Creation

Scenario Outline: Password validation
Given I try to create an account with password "<Password>" Then I should see that the password is <Valid or Invalid>

Examples: Too Short
Passwords are invalid if less than 4 characters

      | Password | Valid or Invalid |
      | abc      | invalid          |
      | ab1      | invalid          |

Examples: Letters and Numbers
Passwords need both letters and numbers to be valid

      | Password | Valid or Invalid |

      | abc1         | valid                  |
      | abcd         | invalid               |
      | abcd1       | valid                  |

By separating the examples into two sets and giving each one a name and description, we’ve explained the rule and given examples of the rule at the same time. "

[Vino Maddy]

Thank u so much Simone and paolo...this can help me a lot

--

Posting rules: http://cukes.info/posting-rules.html
---

You received this message because you are subscribed to a topic in the Google Groups "Cukes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cukes/0Xgw-FDZtOs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cukes+un...@googlegroups.com.

[Andrew Premdas]

Whilst this is quite clever it is a really poor way to write this scenario and scenarios in general. Any example table is somewhat smelly, as is any scenario outline. The more complex they are the stinkier the smell. Consider an alternative

Feature: Password validation on account creation

Scenario: Create account with valid password

  When I create an account with a valid password

  Then my account should be created

Scenario: Create account with invalid password
   When I create an account with an invalid password

   Then I should see an error

    And my account should not be created.

Now this has the benefit that none of the details of HOW you validate the password are in the feature. So when you change what too short means (now its less than 6 characters) you don't have to rewrite all you scenarios. If you are clever about how you implement your scenarios and code you will only need to change one thing.

When details of HOW something is implemented leak into scenarios you are creating duplication problems, because now that Rule appears in two places, the code and the scenario. Keeping these in sync is difficult and expensive.

If you want to write lots of tests to confirm different password validation things (not a common phrase, has a capital letter, has a number, supports all UTF-8 characters etc.) do this with unit tests. In this case it would be easy for them to run 1000 times faster than a cucumber scenario.

On Monday, July 4, 2016 at 8:28:43 AM UTC-7, Vino Maddy wrote:

can we have multiple examples fro same scenario outline 

--

Posting rules: http://cukes.info/posting-rules.html
---

You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Paolo Ambrosio]

For once I disagree with Andrew :-)

In my opinion it depends on what is important to the stakeholders.
Cucumber is a communication tool and if they have to ask the
developers what are the rules for a valid password we have failed at
bridging the gap.

Andrew's example works well if what has been tested is a frontend
application without password validation rules, the example that Simone
pasted from the Cucumber book (excellent read by the way) is instead
relevant where the password rules are implemented (backend or
monolithic frontend).

I agree though that edge cases that are not relevant to the business
should not appear in Cucumber scenarios and should be confined to unit
tests driving the implementation.

[Andrew Premdas]

I agree with this. I would extend my scenarios to deal this. Generally I expect business to not fully understand the nuances of a good/bad password, and certainly not to be capable of extrapolating these from examples. However if certain concepts are important e.g. too short, too simple then I would happily add additional scenarios e.g.

When I create an account with a simple password

Then I should see my password is to simple

And I should be given hints to make my password stronger

One thing that is particularly relevant here is that examples imply rules, they don't specify them. Is

'simples123' too short, too simple, a common phrase ...