Closed. This question is
opinion-based。它当前不接受答案。
想改善这个问题吗？更新问题，以便
editing this post用事实和引用来回答。
2年前关闭。
Improve this question
假设我正在设计一些SaaS服务。而且我需要具有允许用户创建网站的功能。用户可以在管理面板中为每个站点进行特殊设置(例如，小部件的设计)，并获得用于其自己站点的安装服务的唯一代码。
用户故事可能是:
作为登录用户，我想在管理面板中添加新站点，以便我可以分别配置窗口小部件的每个实例，并可以获得将窗口小部件安装到自己站点的唯一代码。
形成
但是，如果我尝试用BDD或GWT(时机时给定)或Gherkin风格描述此功能，那么我将遇到一些麻烦。我从下一个描述开始:
鉴于我已登录到管理面板
而且我在“站点”页面上
当我点击“添加网站”按钮时
然后弹出窗口“添加站点”
正如您在上面的实现中看到的那样，假设站点添加将在弹出窗口中进行(例如，对于UX非常重要)。弹出窗口包含“网站URL”输入字段，带有语言的下拉控件以及“添加”和“取消”按钮。
而且我们遇到了一个奇怪的场景，它只是弹出窗口的原因。这是对的吗？以及如何命名这种情况(“添加站点的表单打开”？)？同样，这种情况只有一种情况(当我单击-弹出窗口时)。也许根本不需要这种情况？我糊涂了...
在这种情况下，我们需要在描述以下内容时创建另一个方案:
GIVEN“添加站点”弹出式表格已打开
当我填写“网站网址”字段时
并点击“添加”按钮
然后将在系统中创建新站点
并且我将转移到我自己网站的列表中
您如何看待，我需要在哪里应用业务规则，例如:
1)创建新站点时，必须生成一个唯一的代码，该代码至少由8个字符组成，包括数字和字母符号。
2)检查不适用于“站点URL”输入字段，并且用户可以输入西里尔符号
3)等等？
我还有很多其他问题，希望对社区有所帮助!
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
在这种情况下，如果您的实现发生更改，则只需更改步骤定义，而不必更改小 cucumber 。不要忘记，这些测试应该解释系统的行为，而不是系统的实现方式。
我认为您还有其他问题与单元测试有关:
创建新站点时，必须生成一个唯一代码，并且
至少由8个字符组成，包括数字和字母
符号=>我会在课堂上这样做，小 cucumber 不会
除非客户明确要求，否则，
条件是“具有所需特性的代码是
为该网站生成”，则必须定义“必填
客户可以阅读和理解的词汇表中的“特性”。 Checks不适用于“站点URL”输入字段，并且用户可以再次输入西里尔符号=>，将其置于与1相同的类级别。除非客户希望能够阅读有关该内容的信息，否则应该在单位级别。 我希望能回答您的问题。如果您想更好地编写更好的小 cucumber 功能，建议使用Dan North的
this article。
编辑11/13/14 根据您的意见，我建议我们退后一步，并描述一种处理您案例中的要求的方法。我必须告诉你我不是BDD专家，而只是分享我自己的个人经验，有关该主题的更多信息，我建议您与
BDD Kickstart和
Cucumber.pro背后的人联系，您将在此找到在线BDD class 。他们将为您提供大量信息和书籍供您阅读。
话虽如此，让我们深入探讨这个主题。
您得到的第一件事就是列出功能或故事，如果您遵循Mike Cohn的故事模板，则该列表将如下所示:
As a <type of user> I want <to do something> in order to <serve a business purpose>
我个人想将业务目标放在第一位，以确保我们在讨论中不会忽略它。您也可能不遵循该模板，这很好，但是请记住，确保与客户一起列出的功能具有业务目的是一个好主意。如果某个功能背后没有任何商业价值，那么执行该功能有什么意义呢？
因此，您确实具有如上所述的功能/故事列表。现在，对于每种功能，都有不同的情况或场景，这就是Dan在
his article中描述的内容。这就是“何时给出”的地方。
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
您可以使用Cucumber或Specflow从UX运行此方案，因此可以使用某种基于浏览器的代理来测试您的应用程序。这通常很慢，因为它会影响整个系统并模拟真实用户。这是一个选择，但我认为这不是最好的。 IMO并非所有测试都应该在UX上运行，而过多的Gherkin功能可能很难维护，因此我更倾向于专注于对快乐或关键的路径(通常我问自己，钱来自哪里)进行全面测试-堆叠并将其余的放置在较低的位置。
如果愿意，您仍然可以将Gherkin用于这些单元测试。但这不是强制性的。您只需要一种方法来向您的客户展示您实际上已经对所有这些特定格式控件和验证检查进行了测试。
这并不意味着您不再使用BDD，如果您是 ruby 主义者或任何其他使用的测试框架，则仍可以在rspec中使用给定时机模式。
希望能澄清所有这些，让我知道是否有任何令人困惑的部分...