[Cucumber] Why isn't there a support for If / Else / While keywords in gherkin

2,140 views
Skip to first unread message

LiohAu

unread,
Feb 19, 2014, 7:06:12 PM2/19/14
to cu...@googlegroups.com
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 retrieval
  When I ask for a password reset
  And I use <informations_kind> username and email
  Then 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 retrieval
  When I ask for a password reset  
  If I use invalid username and email
  Then 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.

Oscar Rieken

unread,
Feb 19, 2014, 7:29:56 PM2/19/14
to cu...@googlegroups.com
On Wed, Feb 19, 2014 at 7:06 PM, LiohAu <julien...@gmail.com> wrote:
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 retrieval
  When I ask for a password reset
  And I use <informations_kind> username and email
  Then 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 retrieval
  When I ask for a password reset  
  If I use invalid username and email
  Then 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.
I dont like the Idea of If Then Else you kind of lose the Idea of what behavior you are expecting to see in the application 
 

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.
 
There a bunch of ways you can rewrite your scenario outline to make it read a lot better. And really if you just have those 2 examples I would probably just leave them as 2 seperate scenarios and not a scenario outline. I think Scenario Outline is better to use when you have a lot of different permutations
 

--
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.

LiohAu

unread,
Feb 19, 2014, 8:00:23 PM2/19/14
to cu...@googlegroups.com
Well, looks like this stupid google group lost my answer, and I don't have the faith to rewrite everything, so shortly : don't try to change the scenario I wrote, because I just wrote it as an argument to discuss the "If" / "Else" keyword feature. So just think about the feature suggestion.

Think about conjugation playing required because the "If" keyword, that we use daily in our natural language, is missing in cucumber.

Quick example :

1°/ I authenticate as X => does the action and fail step if action is not possible
2°/ I should be authenticated as X => check that we are authenticated and fail if we are not

Now 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 authenticated
Then I authenticate as X


Scott Smith

unread,
Feb 19, 2014, 9:11:22 PM2/19/14
to cu...@googlegroups.com
Okay, I'll jump in here.  "If" is not only missing from Cucumber, it's missing from all the popular modern test frameworks that I'm familiar with (rspec, unittest, minispec, etc), and for good reason: test scripts must be scenarios down one path.  If you throw in a conditional, that reduces the understandability of the test.  Or, if you are simply using it as a keyword equivalent to "given" or "when", then I don't know what it means.

It sounds to me like you are looking for a feature similar to "context" in Rspec.

Quick example :

1°/ I authenticate as X => does the action and fail step if action is not possible
2°/ I should be authenticated as X => check that we are authenticated and fail if we are not

Now 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)

Try this:

Scenario: attempt to perform privileged action while not authenticated
Given I am not authenticated
When I attempt to do something privileged
Then I am taken to the login page # a specific result of 'fail'

Scenario: attempt to perform privileged action while authenticated
Given I am authenticated
When I attempt to do something privileged
Then I see the results of doing it.

This flushes out some details that are missing in your "quick example" above:

1.  What does it mean to "fail"?  What can the user do then?
2.  When does authentication happen?  At a login screen?  via ssh machine RSA key?

Does my example take more words than yours?  Yes.  Is it less ambiguous than yours?  Yes.

I find that allowing success/fail definitions in a step makes the step much too complicated.  To reduce complication, it is tempting to reduce preciseness, which is precisely what your example does.

Now, you no longer have to worry about authentication.  Other scenarios specifying privileged operations can specify being authenticated as a precondition, i.e.:

Scenario: do something privileged
Given I am authenticated
When I do something privileged
Then I see the results of doing something privileged
 
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 authenticated
Then I authenticate as X

(Hopefully) addressed above.  You should only have to check that you are authenticated in one scenario; otherwise your design isn't right.

I thank my deities profusely that the if/else capability is not provided in cucumber; it will almost always lead to badly-conceptualized test scenarios.
 

--
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.



--
Scott Smith

http://twitter.com/_ofd (OldFartDeveloper)

Marty Bradley

unread,
Feb 20, 2014, 7:53:03 PM2/20/14
to cu...@googlegroups.com

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.

--

Massimo Manca

unread,
Jan 19, 2015, 5:22:07 AM1/19/15
to cu...@googlegroups.com
Il 20/02/2014 01:29, Massimo Manca ha scritto:
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 retrieval
  When I ask for a password reset
  And I use <informations_kind> username and email
  Then 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 retrieval
  When I ask for a password reset  
  If I use invalid username and email
  Then 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.
Using a scenario outline has many benefits, the bigger is that you are forced to follow a template to design the acceptance test source code and of course also the source code to pass the acceptance test related to the scenario.

"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 .






logo 


Massimo Manca
, Micron Engineering

via della Ferriera, 48 33170 Pordenone PN ITALIA
Tel: 39 0434 1856131 | Mobile: 39 349 4504979
www.micronengineering.it
Twitter LinkedIn SlideShare
Contact me: Skype micron.engineering



logo 


Massimo Manca
, Micron Engineering

via della Ferriera, 48 33170 Pordenone PN ITALIA
Tel: 39 0434 1856131 | Mobile: 39 349 4504979
www.micronengineering.it
Twitter LinkedIn SlideShare
Contact me: Skype micron.engineering



Questa e-mail è stata controllata per individuare virus con Avast antivirus.
www.avast.com


Reply all
Reply to author
Forward
0 new messages