cucumber-attic / gherkin2

A fast Gherkin parser in Ragel (The parser behind Cucumber)
MIT License
382 stars 221 forks source link

Adding terminology for QA to create manual test cases with cucumber #329

Open ghost opened 9 years ago

ghost commented 9 years ago

I see cucumber misused by QA teams so much in the wild that I feel like there should be some bridge behind the behavior driven development with behavior driven automation. Also some way of transitioning manual test cases to automated tests. I think over time that an organization should choose BDD over BDA . Since the real benefits of cucumber lie there. My hope with formalizing a QA domain in Gherkin is that perhaps being able to show the difference between BDD and BDA will un-muddy the waters and address the two different types of approaches that exist in the wild.

everzet commented 9 years ago

Hi. I too see misuses of Gherkin every day by the nature of my job and even treat it as a part of the learning process (half coping, half coaching mechanism) :) That said, I do personally believe that using Gherkin purely for testing without establishing communication part of BDD is very inefficient and painful way of doing automation. I fear officially supporting such usage would only cost us more hatred and horror stories from people burnt by the tool.

ghost commented 9 years ago

Yes I agree with you about the communication part wholeheartedly. I struggled with the idea whether to even submit this pull request. My reaction, had someone else posted this request probably would have been exactly the same as yours. However I am forced to misuse cucumber on a daily basis and part of me, would rather have a language that reflects their use of the tool, than to continue to read reams of "and then and then and then" and be disheartened at how my team is failing to understand how to use the tool, and my inability to change that understanding due to culture, time constraints, the business simply unwilling to change or spend money for training, and I do not have the ability to veto the decision to use cucumber in favor of another tool. I wouldn't expect this to be an advertised feature. It could sit there quietly and only be known to a few people who find it useful. Like texan or lolcat.

tedlandis commented 9 years ago

I welcome this addition, and I agree it could be kept as a option for those of us in situations where we require it. Gherkin works great for QA teams who do not have a standards for authoring their test cases. This could become a gateway syntax, which would ultimately help bring a larger audience to Cucumber and Gherkin. I especially like the fact that the enhancement can be implemented transparently using the existing language feature.

jbpros commented 9 years ago

I'm torn with this one. I understand the purpose and I like the idea of making the "type of use" explicit, in theory. However, I can see how in practice it will be interpreted as if we're endorsing the use of Cucumber (and gherkin friends) as a pure testing tool (something I and others are advocating against).

Should the feature keyword be WeAreDoingItWrong then? :trollface: