假设我正在设计一些SaaS服务。我需要一个允许用户创建网站的功能。用户可以在管理面板中为每个站点进行特殊设置（例如，小部件的设计），并为他自己的站点获取安装服务的唯一代码。
用户故事可能是：
作为一名已登录用户，我想在管理面板中添加新网站，以便我可以单独配置每个小部件实例，并可以为我自己的网站获取安装小部件的唯一代码。
表格
但是，如果我尝试用BDD或GWT（当时给定）或Gherkin风格来描述这个功能，我将面临一些麻烦。我从下一个描述开始：
GIVEN我已登录管理员面板 我和＃34;网站＆＃34;页
点击＆＃34;添加网站＆＃34;按钮
然后弹出窗口＆＃34;添加网站＆＃34;来吧
正如您在上面的实现中所见，假设站点添加将在弹出窗口中（例如，它对于UX非常重要）。弹出窗口包含站点URL输入字段，带语言的下拉控件和＆＃34;添加＆＃34;和＆＃34;取消＆＃34;的按钮。
我们得到了一个奇怪的场景，它负责弹出窗口。这是对的吗？我如何命名这个场景（＆＃34;添加网站＆＃39;表格开放＆＃34; ??）？此场景也只有一种情况（当我点击 - 弹出打开）。也许根本不需要这种情况？我很困惑......
在这种情况下，我们需要在描述时创建另一个场景：
GIVEN＆＃34;添加网站＆＃34;弹出窗体打开
当我填写＆＃34;网站网址＆＃34;领域 并点击＆＃34;添加＆＃34;按钮
那么新网站将在系统中创建 我将转移到我自己的网站列表
您如何看待，我需要在哪里应用业务规则，例如： 1）创建新站点时，必须生成唯一代码，并且至少包含8个字符，包括数字和字母符号。 2）检查不适用于站点URL输入字段，用户可以输入西里尔符号 3）等？
我对社区帮助有很多其他问题和希望！
答案 0 :(得分：6)
BDD的目的是尽可能远离实施细节。此方案有多个实现细节：
GIVEN I'm logged into admin panel AND I'm on "Sites" page
WHEN I click "Add site" button
THEN Pop-up window "Add site" come up
对于这个具体的例子，更好的方法是：
GIVEN I'm an authorised administrator
WHEN I enter all the required information for a new site and save it
THEN I should see that site in my own sites list
在这种情况下，如果您的实施发生变化，您只需更改步骤定义，就不必更改小黄瓜。不要忘记那些测试应该解释系统的行为，而不是它的实现方式。
在我看来，你所拥有的其他问题与单元测试更相关：
创建新网站时，必须生成唯一代码 由至少8个字符组成，包括数字和字母 symbols =＆gt;我会在课堂上做，小黄瓜不会 除非客户明确要求，否则适当 条件是“然后具有所需特征的代码是 为该网站生成“并且您必须定义”必需 特征“在客户可以阅读和理解的词汇表中。
支票不适用于网站网址输入字段，用户可以输入西里尔符号=＆gt;再次，将它放在与1级相同的级别，除非客户希望能够阅读有关它的内容，它应该在单元级别。
我希望能回答你的问题。如果你想更好地了解如何编写更好的小黄瓜功能，我推荐Dan North的this article。
编辑11/13/14
根据您的意见，我建议我们退后一步，描述一种处理您案件要求的方法。我必须告诉你，我不是BDD专家，只是分享我自己的个人经历，有关这个主题的更多信息，我建议你联系BDD Kickstart和Cucumber.pro后面的人。你会发现在线BDD课程。他们将能够为您提供大量信息和书籍供您阅读。
话虽如此，让我们深入探讨这个问题。
你得到的第一件事是一系列功能或故事，如果你跟随迈克科恩的故事模板看起来像：
As a <type of user> I want <to do something> in order to <serve a business purpose>
我个人希望首先考虑商业目的，以确保我们不会在讨论中跳过它。您可能也不会遵循该模板，这很好，但请记住，确保您与客户列出的功能具有业务目的是一个好主意。如果某个功能背后没有商业价值，那么无论如何都要做到这一点......
所以你有一个如上所述的功能/故事列表。现在，对于这些功能中的每一个，都有不同的案例或场景，这就是Dan在his article中所描述的内容。这是引入Given-When-Then的地方。
Scenario: Title
Given <some context>
When <there is an event>
Then <something happens>
这些场景中的每一个都是关于此特定功能在不同上下文中的行为的示例。它们是特定功能的不同验收标准，客户将其描述为系统的预期行为。他们应该不了解任何实施细节。所以像：
Given I am on page "First page"
When I click "Hello world"
Then I should see "You clicked hello world"
此编辑之前描述的原因是错误的。
我们假设以下功能：
In order to save time when answering clients requests, as a webmaster,
I want to be able to manage the list of websites I am responsible for
这个故事的场景将是：
Scenario 1: Show a list of websites
GIVEN I am an authorised administrator
AND I am managing several websites
THEN I should see a list of all the sites I manage
Scenario 2: Add website to list
GIVEN I am an authorised administrator
WHEN I enter all the required information for a new site and save it
THEN I should see that site in my own sites list
Scenario 3: Edit website from list
GIVEN I am an authorised administrator
WHEN I edit the site informations
THEN I the changes should be visible in my sites list
...
现在如果你想进入数据验证，例如“网站应该有一个标题”。对我来说，有两种不同的方法来解决这个问题。您可以从用户的角度使用全栈测试或测试来测试，在对象级别进行一些验证。
让我们假设以下情形：
Scenario: New site has no title
GIVEN I'm an authorised administrator
WHEN I forget to fill in the title for a new site and save it
THEN I should be warned the site is not valid
您可以使用黄瓜或specflow从UX运行此方案，因此使用某种基于浏览的代理来测试您的应用程序。这通常很慢，因为它击中整个系统并模拟真实用户。这是一个选择，但我不认为这是最好的。 IMO并不是所有的测试都应该针对用户体验进行操作，并且有太多的Gherkin功能可能会让人难以维护，这就是为什么我更喜欢专注于拥有快乐或关键的路径（通常我会问自己，钱来自哪里）测试完整 - 搁置并将其余部分放在较低的水平。
如果您愿意，您仍然可以使用Gherkin进行这些单元测试。但这不是强制性的。您只需要向客户展示您实际上对所有这些特定格式控件和验证检查进行测试。
这并不意味着你不再使用BDD了，如果你是rubyist，或者你使用的任何其他测试框架，你仍然可以在rspec中使用当时给定的模式。
希望澄清这一切，请告诉我是否有任何令人困惑的部分......
答案 1 :(得分：1)
我认为Marc在这个问题上应该得到一个很大的绿色标记，这要归功于他非常彻底的答案！
我只想添加一些评论。
如果您希望以每个人（包括非技术娴熟的人）都能理解并且Gherkin的Given / When / Then为您工作的形式捕捉业务需求，那就去吧。没有什么可以迫使您自动化所有场景。
您的软件由通常通过不同界面（UI，HTTP，API等）响应类似行为的图层组成。如果您想使用自动小黄瓜场景描述细粒度的业务规则（即站点名称约束），您可以编写直接与域层对话而不是通过用户界面的步骤定义。这可能仍然会给你一定程度的信心。
作为旁注，如果您的目的是与非技术人员分享您的测试/要求，我建议不要在经典测试框架中使用Given / When / Then（即只有开发者可以看到的那些！）。 / p>
最重要的是，BDD是关于更好的沟通：尝试更多地谈论，在流程的早期让您的开发人员（或其中一些人）参与进来，以便他们更快地获得更多知识。将Gherkin场景正式化进入第二阶段。自动化它们甚至应该是你的优先级列表！