Ruby-on-rails 如何学习/教黄瓜小黄瓜

How to learn/teach Gherkin for Cucumber

提问by Timothy T.

I'd like to enable the business analysts to be able to write all of their specs for features, scenarios and steps that is Cucumber friendly using Gherkin.

我想让业务分析师能够使用 Gherkin 编写对 Cucumber 友好的特性、场景和步骤的所有规范。

I've read some of the basic info on the github site for Cucumber and from doing a quick Google search but wanted to know if there were recommended resources for getting non-technical folks to be able to write comprehensive BDD using Gherkin (I assume that's the preferred language for Cucumber tests to be created in).

我已经在 github 站点上阅读了 Cucumber 的一些基本信息，并通过 Google 快速搜索了解了一些基本信息，但想知道是否有推荐的资源让非技术人员能够使用 Gherkin 编写全面的 BDD（我认为是用于创建 Cucumber 测试的首选语言）。

Thanks.

谢谢。

回答by mrD

What I did with the business analysts in our company was to teach them the structure by giving them the keywords: Given, When, Then, Andfor Scenarios and In order to, As aand I want tofor Features.

我对我们公司的业务分析师所做的是通过给他们以下关键字来教他们结构：Given、When、Then、Andfor Scenarios 和In order、As a和I want tofor Features。

Then I gave them a simple example and told them to write down their own features as they thought they should be written. Surprisingly enough the structure was self explanatory and the features they wrote became a great start.
The only big problem was that they had contained to much logic in each scenario step. I solved that by iteratively asking "why?" which in most cases revealed the core functionality they were after and we re-wrote the scenarios accordantly.

然后我给了他们一个简单的例子，让他们按照他们认为应该写的方式写下自己的特点。令人惊讶的是，结构是不言自明的，他们编写的功能成为了一个很好的开始。
唯一的大问题是他们在每个场景步骤中都包含了很多逻辑。我通过反复问“为什么？”来解决这个问题。在大多数情况下，这揭示了他们所追求的核心功能，我们相应地重新编写了场景。

By giving them the guidelines and letting them write the features themselves they got their hands dirty and were forced to think about what they wrote. Today they have a much better understanding and the "why?" iterations are not that common anymore.

通过给他们指导并让他们自己编写功能，他们弄脏了他们的手，并被迫考虑他们写的内容。今天，他们对“为什么？”有了更好的理解。迭代不再那么常见了。

Ofcourse you need to have the business analysts and the developers to work closely together and the features the analysts write should only act as a start. Remember that the Cucumber features are just a common language between the analysts and the developers. They still need to sit together often to be able to speak with each other :)

当然，您需要让业务分析师和开发人员密切合作，分析师编写的功能应该只是一个开始。请记住，Cucumber 功能只是分析师和开发人员之间的通用语言。他们仍然需要经常坐在一起才能互相交谈:)

回答by Ryan Bigg

http://cukes.infois a great resource for teaching people how to write them. Ben Mabey also made a great presentation on Cucumberat Mountain West Ruby Conference 2009.

http://cukes.info是教人们如何编写它们的绝佳资源。Ben Mabey 还在Mountain West Ruby Conference 2009上做了关于 Cucumber 的精彩演讲。

回答by JosephL

Having just worked on an agile project using cucumber for the first time I think that the best way to learn Cucumber and Gherkin is to get your hands dirty.

第一次使用黄瓜进行敏捷项目时，我认为学习黄瓜和小黄瓜的最佳方法是亲自动手。

I may be wrong but I get the impression from your question you are wanting to train your BAs to write Gherkin; then they will write a bunch of features and hand them to developers.

我可能错了，但我从你的问题中得到的印象是你想训练你的 BA 写小黄瓜；然后他们将编写一堆功能并将它们交给开发人员。

This is definitely not the way to go. It is much better to have BA's devs and users (if possible) working together to write your scenarios and build them as you go. Then you all learn together what works and what doesn't.

这绝对不是要走的路。让 BA 的开发人员和用户（如果可能）一起编写您的场景并在您进行时构建它们会好得多。然后你们一起学习什么有效，什么无效。

We tried having a BA write entire features and hand them over. We (the devs) ended up having to do major rewrites because the implementation ended up different to that originally envisioned by the BA. We also had to change the syntax of the steps and do find and replace through the whole file.

我们尝试让 BA 编写整个功能并将其移交。我们（开发人员）最终不得不进行重大重写，因为最终实现与 BA 最初设想的不同。我们还必须更改步骤的语法，并在整个文件中进行查找和替换。

Do one scenario at a time, get it working then move on to the next. An iterative approach reduces wasted effort and makes sure you all understand how you want the app to behave.

一次做一个场景，让它工作，然后继续下一个。迭代方法可以减少浪费的精力，并确保大家都了解您希望应用程序的行为方式。

In terms of how to write steps it is best to start with the ones that come with Cucumber and copy and adapt them as you work on your project to fit your particular application. There is no right or wrong, it is what works for you. The documentation on the cucumber sites is generally good and will be a valuable resource as you learn more.

在如何编写步骤方面，最好从 Cucumber 附带的步骤开始，并在您处理项目时复制和调整它们以适合您的特定应用程序。没有对与错，这对你有用。黄瓜站点上的文档通常很好，随着您了解更多信息，它将成为宝贵的资源。

回答by Gaspar Nagy

We are teaching Gherkin (for SpecFlow) in a similar way, how mrD has described it.

我们正在以类似的方式教授 Gherkin（用于 SpecFlow），mrD 是如何描述它的。

I think it is very important though, that the audience is familiar with the main intention of "Specification by Example", agile requirement analysis and BDD, so we usually start discussing the background first. We also show a sample Gherkin scenario and explain the very basics (like Given/When/Then/But and tables).

我认为这很重要，但观众熟悉“实例化说明”、敏捷需求分析和 BDD 的主要意图，所以我们通常先开始讨论背景。我们还展示了一个示例小黄瓜场景并解释了非常基础的内容（如 Given/When/Then/But 和表格）。

Than we take a simple example story (that is quite familiar to everyone), like "add items to shopping cart" (with some orientation, of course) and let them formulate the acceptance criteria in small groups.

然后我们举一个简单的例子故事（大家都很熟悉），比如“将商品添加到购物车”（当然有一些方向），让他们以小组形式制定验收标准。

After that every team shows / explains their solutions and we discuss the good and bad practices that were present. After the second team, you can see almost all of the most important (good or bad) practices appearing.

之后，每个团队展示/解释他们的解决方案，我们讨论存在的好的和坏的做法。在第二个团队之后，您可以看到几乎所有最重要的（好的或坏的）实践出现。

I also type in the concluded solution, and show here alternative ways of describing the scenarios (background, scenario outline, etc.). If there is enough time, I also show how to automate & implement the imagined functionality based on that. This also help to understand some important rules to follow, that makes the automation much easier.

我还输入了总结的解决方案，并在此处展示了描述场景的替代方法（背景、场景大纲等）。如果有足够的时间，我还会展示如何在此基础上自动化和实现想象中的功能。这也有助于理解要遵循的一些重要规则，从而使自动化变得更加容易。

Although, I never know upfront what will happen, usually this exercise is the best part of our BDD training.

虽然我从来不知道会发生什么，但通常这个练习是我们 BDD 培训中最好的部分。

回答by Rimian

The RSpec book has a couple of chapters in it that are relevant to Business Analysts:
http://pragprog.com/book/achbd/the-rspec-book

RSpec 书中有几章与业务分析师相关：http:
//pragprog.com/book/achbd/the-rspec-book

回答by thion

I think the best way to learn is to start writing. Gherkin & Cucumber are easy to learn but difficult to master, so it's important to get to practical examples as soon as possible.

我认为最好的学习方法是开始写作。Gherkin & Cucumber 易于学习但难以掌握，因此尽快获得实际示例非常重要。

While it's important to get started by writing your first scenarios, you also need some resources to establish good habits and understand key practices. I wrote a book that could help. “Writing Great Specifications”is, I hope, a good way to learn Gherkin and Cucumber. It covers patterns and antipatterns as well as key techniques for writing great scenarios. :) If you have any questions, you can always hit me up on Twitter.

虽然从编写第一个场景开始很重要，但您还需要一些资源来建立良好的习惯和了解关键实践。我写了一本可以提供帮助的书。我希望，“编写伟大的规范”是学习小黄瓜和黄瓜的好方法。它涵盖了模式和反模式以及编写出色场景的关键技术。:) 如果你有任何问题，你可以随时在Twitter 上联系我。

If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2:)

如果您有兴趣购买“Writing Great Specifications”，您可以使用促销代码39nicieja2节省 39% :)

Other great resources:

其他很棒的资源：

• “Specification by Example” by Gojko Adzic if you're interested in software development processes and high-level engineering practices.
• “BDD in Action” by John Smart if you don't mind reading testing code in Java. It's a comprehensive end-to-end view on defining and testing software requirements.
• “Behaviour-Driven Development” by Liz Keogh if automated testing doesn't ring a bell, but you want to understand how specifications with examples affect your business analysis processes.
• “The Cucumber Book: Behaviour-Driven Development for Testers and Developers” by Matt Wynne and Aslak Helles?y
• “The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends” by David Chelimsky, Dave Astels, Zach Dennis, Aslak Helles?y, Bryan Helmkamp, Dan North

• 如果您对软件开发过程和高级工程实践感兴趣，请阅读 Gojko Adzic 的“Specification by Example”。
• 如果您不介意阅读 Java 中的测试代码，John Smart 的“BDD in Action”。它是关于定义和测试软件需求的全面的端到端视图。
• Liz Keogh 的“行为驱动开发”，如果自动化测试没有敲响警钟，但您想了解带有示例的规范如何影响您的业务分析流程。
• “黄瓜书：测试人员和开发人员的行为驱动开发”，作者：Matt Wynne 和 Aslak Helles?y
• “RSpec Book：行为驱动的 RSpec、Cucumber 和 Friends 开发”作者：David Chelimsky、Dave Astels、Zach Dennis、Aslak Helles?y、Bryan Helmkamp、Dan North

回答by Aravin

• Best way to learn Gherkin is to read the Behat documents first: http://behat.readthedocs.org

• Then read official documents from cucumber site: https://cucumber.io/docs/reference

• Also, you can read Guru99 article to write your first cucumber script: http://www.guru99.com/your-first-cucumber-script.html

• 学习 Gherkin 的最佳方法是先阅读 Behat 文档：http: //behat.readthedocs.org

• 然后从黄瓜网站阅读官方文档：https: //cucumber.io/docs/reference

• 此外，您可以阅读 Guru99 文章来编写您的第一个黄瓜脚本：http: //www.guru99.com/your-first-cucumber-script.html