小黄瓜描述测试或功能？

Question

这是我碰到和我的同事一个有趣的话题，我有对此事的不同看法。如果你的小黄瓜准确地描述了测试的内容，或者只显示你在测试中试图达到的商业逻辑。

我一直在工作中遇到的最大例子是，如果你有权访问项目A，那么你应该能够访问A.我们可以有20种不同类型的用户访问A，所以我们只选择1（保持我们的测试套件运行40小时）。那么哪个更好？

甲

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用户。

所以介绍测试是做什么

而B描述（访问项目A只是一个用户）访问项目A所需的功能（与访问项目A型4用户身份登录）

你问之前，我们如何决定谁有权访问项目A是SQL调用数据库中寻找链接到用户的特定项目。

Answer 1

对于正在测试的业务逻辑的黄瓜试验 - 作为验收试验 - 不HTE具体的实施细则。所以你应该做第二个不是第一个。如果要运行X型，Y型和边缘案例的测试，则您的请求规范或集成测试可以更多地与特定关联。

我觉得人能想到这一点 - 它不是一个艰难快速的规则 - 就像这样：

单元测试在同一时间以隔离方法和测试的一件事。模拟&存根其他一切隔离什么被测试。

集成测试，以测试事物如何互动起来，以测试你的筹码的较大部分，包括多个物体之间的相互作用。有人会争辩说，你在这里测试了所有的汤，但我认为在一个大的复杂应用程序中有一个地方可以测试大量的片段，同时还不能测试完整的请求周期。

请求规格 - 有时是简单的应用程序，这些是几乎一样的集成测试，在其他情况下，我会做集成测试的一切，除了请求堆栈和专门分离出来我的要求的规格。意见会有所不同。

验收试验 - 这是你与你的问题坐 - 在测试被写在普通的商业语言，避免了功能定义中的技术实现细节。

不管怎样，即使你忽略的测试堆栈的其他思想，在具体的问题你问随时随地B.

Answer 2

我想说选项B是更好的。 “类型4用户”听起来像是一个实现细节。

但是，如果要求所有用户类型都有访问权限，那么它也应该成为规范的一部分。在这种情况下，测试应该指定并测试所有的用户类型。

Answer 3

我会说B更好。对于“类型4用户”你可以把它变成一个背景的一部分：

Backgound : User is logged in 
Given "Type 4 user" is logged in 

使用4类用户的占位符将其置于“”这样你就可以重复使用登录其他用户的步骤定义有权访问项目A