4

这是我遇到的一个有趣的话题，我和我的同事对这个问题有不同的看法。您的 Gherkin 是否应该准确描述测试在做什么，或者只显示您在测试中尝试实现的业务逻辑。

我在工作中经常遇到的最大的例子是，如果您可以访问项目 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

或乙

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 调用，以查找链接到用户的特定项目。

4

3 回答 3

8

对于黄瓜测试，您正在测试业务逻辑 - 作为验收测试 - 而不是特定的实现细节。所以你应该做第二个而不是第一个。如果您想针对 X 型、Y 型和边缘案例运行测试，您的请求规范或集成测试可能会更依赖于具体情况。

我认为人们可以想到这一点 - 这不是一个硬性规则 - 就像：

单元测试以隔离方法并一次测试一件事。模拟和存根所有其他内容以隔离正在测试的内容。

集成测试以测试事物如何交互以测试堆栈的大部分，包括多个对象的交互。有些人会争辩说你在这里测试了所有的东西，但我认为在一个大型复杂应用程序中有一个地方可以测试很多集成的部分，同时还没有测试完整的请求周期。

请求规范 - 有时在简单的应用程序中，这些与集成测试几乎相同，在其他情况下，我将对请求堆栈以外的所有内容进行集成测试，并专门分离出我的请求规范。意见会有所不同。

验收测试 - 这是您处理问题的地方 - 测试是用简单的业务语言编写的，并且避免了功能定义中的技术实现细节。

无论如何，即使您忽略了测试堆栈其余部分的想法，在您要求的特定问题中选择 B。

于 2013-03-26T02:02:21.397 回答
0

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

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

于 2013-03-26T16:27:11.487 回答
0

我会说B更好。对于“类型 4 用户”，您可以使其成为背景的一部分：

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

通过将类型 4 用户放置在 "" 中来使用占位符，这样您就可以为有权访问项目 A 的其他用户重复使用登录的步骤定义

于 2013-04-11T06:45:44.033 回答