这是我遇到的一个有趣的话题，我的同事和我对此事有不同的看法。您的小黄瓜应该准确描述测试的内容，或者只显示您在测试中尝试实现的业务逻辑。
我在工作中遇到的最大例子是，如果你有权访问项目A，那么你应该能够访问A.我们可以有20种不同类型的用户可以访问A，所以我们只选择1（保持我们的测试套件运行40小时）。那么哪个更好＆＃34;？
A
Scenario: A user with access to item A can access A
Given I am a type 4 user with access to item A
When I try to access A
Then I am granted access to A
或B
Scenario: A user with access to item A can access A
Given I am a user with access to item A
When I try to access A
Then I am granted access to A
注意给定语句（类型4用户）的差异
在步骤定义中，我们将使用类型4用户进行测试，但测试并非特定于类型4用户。任何具有项目A的用户都将参与此测试，我们只使用类型4用户，因为我们需要用户类型才能登录。
所以A描述了测试的作用（使用能够访问项目A的类型4用户登录）
B描述了访问项目A（只有具有项目A访问权限的用户）所需的功能
在您询问之前，我们如何确定谁有权访问项目A是对数据库的SQL调用，以查找链接到用户的特定项目。
答案 0 :(得分：8)
对于黄瓜测试，您正在测试业务逻辑 - 作为验收测试 - 而不是特定的实现细节。所以你应该做第二个而不是第一个。如果要对类型X，类型Y和边缘情况运行测试，则您的请求规范或集成测试可能与特定内容更紧密相关。
我认为人们可以想到这一点 - 这不是一个严格的快速规则 - 就像：
单元测试以隔离方法并一次测试一件事。模拟＆amp;除了其他所有内容以隔离正在测试的内容。
集成测试，用于测试事物如何相互作用以测试堆栈的大部分，包括多个对象的交互。有些人认为你在这里测试所有的汤都是坚果，但我认为在一个大型的复杂应用程序中有一个地方可以测试大量的集成，同时还没有测试完整的请求周期。
请求规范 - 有时在简单的应用程序中这些与集成测试几乎相同，在其他情况下，我将对除请求堆栈之外的所有内容进行集成测试，并专门分离出我的请求规范。意见会有所不同。
验收测试 - 您可以在这里查看问题 - 测试以简单的商业语言编写，并避免在功能定义中使用技术实现细节。
无论如何，即使你忽略了对测试堆栈其余部分的想法，在你要求的具体问题中也要去找B。
答案 1 :(得分：0)
我会说选项B更好。 “类型4用户”听起来像一个实现细节。
但是，如果要求所有用户类型都具有访问权限，那么它也应构成规范的一部分。在这种情况下，测试应指定并测试所有用户类型。
答案 2 :(得分：0)
我会说B更好。对于“Type 4用户”，您可以将其作为背景的一部分：
Backgound : User is logged in
Given "Type 4 user" is logged in
将类型4用户的占位符放在“”中，以便您可以将已登录的步骤定义重新用于有权访问项目A的其他用户