Everything is in the title, but here is my main argument :In my opinion, this scenario outline that uses the concept of placeholders that are replaced by examples values :Scenario Outline: Password retrievalWhen I ask for a password resetAnd I use <informations_kind> username and emailThen I should see the message "<message>"Examples:| informations_kind | message || invalid | Your password could not be retrieved. || valid | Your password has been successfully retrieved. |Is less readable for non-technical people than a scenario like this one :Scenario: Password retrievalWhen I ask for a password resetIf I use invalid username and emailThen I should see the message "Your password could not be retrieved."Else I should see the message "Your password has been successfully retrieved.""If" keyword would be a step that skip everything until an "Else" step when the "If" step definition returns false.
Yes, people will use these keywords to make ugly things that does not respect cucumber philosophy ? But for other that will use these keywords with caution it will be really useful.PS : When reading threads in this group I have the feeling that cucumber is like a dictatorship, I assume that you, cucumber authors, love your product, and try to make the best product, but don't forget that your opinion can be wrong, so either people posting questions here are doing every scenarios wrong, either you're not considering enough the use of cucumber made by your community and potential customers.Thanks for reading.
--
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/groups/opt_out.
Quick example :1°/ I authenticate as X => does the action and fail step if action is not possible2°/ I should be authenticated as X => check that we are authenticated and fail if we are notNow how do you write a step that authenticates if you are not already and else does nothing ? (A step that you will probably use in your background)
You'll maybe use something like that : I am authenticated as X. Now you have a step that makes an If, but that is less readable, and does not allow you to reuse your step 1° to write something like that :If I am not authenticatedThen I authenticate as X
--
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/groups/opt_out.
Um maybe but in this case they aren't wrong. If you're creating conditional logic in your user stories or acceptance criteria it indicates a level of complexity that would be clearer if broken into multiple user stories. I've seen thing like this turn into pseudo code. Not very helpful for the business. BDD, is a requirements gathering tool not a testing tool.
--
Il 20/02/2014 01:06, LiohAu ha scritto:
Everything is in the title, but here is my main argument :
In my opinion, this scenario outline that uses the concept of placeholders that are replaced by examples values :
Scenario Outline: Password retrievalWhen I ask for a password resetAnd I use <informations_kind> username and emailThen I should see the message "<message>"
Examples:| informations_kind | message || invalid | Your password could not be retrieved. || valid | Your password has been successfully retrieved. |
Is less readable for non-technical people than a scenario like this one :
Scenario: Password retrievalWhen I ask for a password resetIf I use invalid username and emailThen I should see the message "Your password could not be retrieved."Else I should see the message "Your password has been successfully retrieved."
I don't agree. Every time you insert an if instruction you are dividing your scenario in 2 halves so there are 2 paths and if you can nest an if you could realize 2^n paths. The idea behind Gherkin is different.I don't agree also. The idea behind Gherkin is to follow only one path and this is quite good because in this way you shouldn't need to test if the scenario is logically correct or not.
"If" keyword would be a step that skip everything until an "Else" step when the "If" step definition returns false.
Yes, people will use these keywords to make ugly things that does not respect cucumber philosophy ? But for other that will use these keywords with caution it will be really useful.
I don't agree they aren't useful in the context of Gherkin.
PS : When reading threads in this group I have the feeling that cucumber is like a dictatorship, I assume that you, cucumber authors, love your product, and try to make the best product, but don't forget that your opinion can be wrong, so either people posting questions here are doing every scenarios wrong, either you're not considering enough the use of cucumber made by your community and potential customers.
May be right but I think it is right that the authors may decide to implement or not a requested feature. If you don't like Gherkin you can write a Gherkin-like language implementing what you want.
--
Thanks for reading.
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/groups/opt_out.
![]()
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus .
![]()
Massimo Manca, Micron Engineering
via della Ferriera, 48 33170 Pordenone PN ITALIA
Tel: 39 0434 1856131 | Mobile: 39 349 4504979www.micronengineering.it
![]()
![]()
Contact me:micron.engineering
![]() |
![]() Massimo Manca, Micron Engineering via della Ferriera, 48 33170 Pordenone PN ITALIA Tel:
39 0434 1856131 | Mobile:
39 349 4504979
www.micronengineering.it |
![]() |
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
|