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
- 如果“站点”页面变为“Awesome Site”页面或被简单删除会怎样？
- 如果“添加网站”不再是一个按钮会怎样？
- 如果不是弹出窗口而是发生重定向会发生什么
- 之后会发生什么？价值仅仅是显示弹出窗口吗？我猜不是……
对于这个具体的例子，更好的方法是：
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 个字符组成，包括数字和字母
符号 => 我会在课堂上做，小黄瓜不会
适当的，除非客户特别要求，然后
条件是“那么具有所需特征的代码是
为该站点生成”，您必须定义“必需
特征”在客户可以阅读和理解的词汇表中。
检查不适用于站点 URL 输入字段，用户可以再次输入西里尔符号 =>，将其置于与 1 相同的类级别。除非客户希望能够阅读某些内容关于它，它应该在单元级别。
我希望这能回答你的问题。如果您想更好地了解如何编写更好的小黄瓜功能，我推荐 Dan North 的this article。
编辑 2014 年 11 月 13 日
根据您的 cmets，我建议我们退后一步，描述一种处理您的案例要求的方法。我必须告诉你，我不是 BDD 专家，只是分享我自己的个人经验，有关该主题的更多信息，我建议你与 BDD Kickstart 和 Cucumber.pro 背后的人联系，你可以在网上找到BDD 课程。他们将能够为您提供大量信息和书籍供您阅读。
话虽如此，让我们进入主题。
您得到的第一件事是功能或故事的列表，如果您按照 Mike Cohn 的故事模板，这些功能或故事将如下所示：
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
您可以使用 cucumber 或 specflow 从 UX 运行此场景，因此使用某种基于浏览的代理来测试您的应用程序。这通常很慢，因为它会影响整个系统并模拟真实用户。这是一个选择，但我认为这不是最好的。 IMO 并非所有测试都应该针对 UX 运行，并且拥有太多 Gherkin 功能可能很难维护，这就是为什么我更喜欢专注于让快乐或关键路径（通常我问自己，钱从哪里来）测试完整-stack 并将其余的放在较低的级别。
如果您愿意，您仍然可以将 Gherkin 用于这些单元测试。但这不是强制性的。您只需要一种方式向您的客户展示您实际上已经对所有这些特定格式控制和验证检查进行了测试。
这并不意味着您不再使用 BDD，如果您是 rubyist 或您使用的任何其他测试框架，您仍然可以在 rspec 中使用 given-when-then-should 模式。
希望澄清这一切，如果有任何令人困惑的部分，请告诉我......