如何使用 Gherkin 测试基于授权的过滤器？
How to test filters based on authorization using Gherkin?
我不明白当没有实际的业务操作来测试某些东西时，场景应该是什么样子。
下面的场景够好吗？不明白怎么转换成Past, Action, Future序列
Scenario:
Given The system contains the following users
| email | role |
| admin@example.com | ADMIN |
| user@example.com | USER |
And The system contains the following Products
| Name | Active |
| Product1 | true |
| Product2 | false |
Then The list of Products for 'admin@example.com' user should contain the following entries
| Name | Active |
| Product1 | true |
| Product2 | false |
And The list of Products for 'user@example.com' user should contain the following entries
| Name | Active |
| Product1 | true |
就个人而言，这就是我编写该场景的方式：
Scenario Outline: Viewing inactive products in different roles
Given I am logged in as <user_role>
And the system contains the active product "product1"
And the system contains the inactive product "product2"
When I view the available products
Then I should see the "product1" product
And I <should_see_inactive?> see the "product2" product
Examples:
| user_role | should_see_inactive? |
| an admin | should |
| a user | should not |
您似乎在此处测试的是角色中的特定用户是否具有查看非活动产品的正确访问级别。
您的陈述的编写方式似乎应该编写 2 个场景，并且当您为 2 个不同的用户组测试相同的内容以显示差异时，我正在使用 Scenario Outline
tl;博士
沟通困难。将 behavior（即 "when" 子句）嵌入到需求中更好（IMO）。
您发布的建议需要解释
您发布的建议实际上并没有告诉我要求是什么！相反，我现在必须弄清楚潜在的意图是什么才能得到你想要的东西。换句话说，我必须 "reverse engineer" 预期的逻辑。这是传达需求的一种更糟糕的方式。事实上，这是一种更糟糕的交流方式。
这是对您发布的建议的一种解释
Given a user who is not an admin
And products which are not active
When that user ever views any products
Then he cannot view the inactive products
Given a user who is an admin
And products which are not active
And products which are active
When that user ever views any products
Then he can view the both sets of products
但是，在您发布的建议中，是否应该允许非管理员查看 非活动产品？这是一个合理的问题。
如果你只说某些产品是"for"某某，那我不知道你是说"ownership"还是"viewability."如果我编写了允许所有用户查看其他人的产品的代码？如果您单击管理员用户配置文件，您会看到所有产品。如果您单击非管理员用户配置文件，您只会看到活动产品。看？我已经根据您的要求成功地为每个用户策划了列表。但是，如果您的意图是基于安全性的呢！不知何故，非管理员根本不应该看到 UI 中存在的那些产品。这是一个非常不同的要求，但您的文章并没有区分它。这是另一个很好的解释：如果你想让我过滤的唯一东西是某种 "selectibility" 怎么办？即：我可以查看所有产品，但我不能 select/attach/use 非活动产品（除非我是管理员）。同样，这是对策展和可见性的不同解释。
您可能会声称 "context" 使这一点显而易见。考虑到应用程序的页面流，没有人会误解其意图。然而，当你看到足够多的程序发生重大变化后，你会更看重 而不是 取决于 "context" 使事情变得 "obvious." 或者有人只是将你的小黄瓜文件拆分成什么两部分。如果周围的要求是正确解释这个的必要条件，那么现在我们通过改进代码中的文件结构就已经失去了它。
总之，沟通难。我相信将 行为 嵌入到需求中可以减少人们误解它的可能性。
为什么我更喜欢我的建议（其中有一个 "when" 子句）
相比之下，这个答案中的建议是字面意思。无论以后添加或更改了哪些其他权限层或数据库架构如何更改，我们都知道要求是什么。
我认为行为驱动的需求也可以帮助您更好地与产品负责人沟通。我敢打赌产品所有者会说 "I don't want anyone else (other than admins) being able to see inactive products." 我的建议几乎是产品所有者在那种情况下会说的。您的建议必须 "translate" 程序员喜欢思考的 "data-driven" 视图的真实意图。但是，我们 "translate" 将他们的注释转换成不同格式（如数据结构图）的次数越多我们冒着假设和误解的风险。这样的翻译 "lossy." 在我们的职业生涯中，我们听到产品所有者说 "what? That's not what I said!" 的次数越多，我们就越会对 "implicit" 沟通或 "obvious" 需求翻译感到不自在。相反，明确说明每一个文字要求。
根据我的经验，产品负责人总是首先考虑更多 behavior/customer-driven 个方面。不过这只是我的经验。
关于小黄瓜
Gherkin 只是一个工具，所以它只做一件事并且做好一件事：它迫使您思考 行为 驱动开发 (BDD)。如果您使用小黄瓜，则必须根据 "input" 行为及其所需的结果来编写内容。否则你用错了工具。
相反，您应该决定您是否认为 BDD 是一种强迫自己遵循的好哲学。如果您认为遵循该理念是好的，那么您将需要不断改写要求，直到出现 "when" 语句。一些人（包括我）认为强迫自己发表 "when" 声明的练习是好的。
此外，gherkin 与其他文档并不互斥。例如，您仍然会有 ERD 图、UI 模型等。事实上，您甚至可以从其他设计文档中引用小黄瓜场景。 Gherkin 旨在帮助您了解您是否按照客户的要求进行操作，而不是您是否将代码设计得很好。其他规范会这样做，并且它们可以协同工作。
不仅如此，"requirements" 本身也有层次，并以不同的媒介呈现。例如，您可能需要产品所有者为客户编写的 "sign-off" 文档。该文档的格式与小黄瓜 非常 不同，因此很好。在另一个极端，你有一个 ERD 图。我将小黄瓜视为 "in between" 需求抽象级别。
此外，回归测试应该变得简单。使用小黄瓜，您甚至可以将其自动化。然而，再一次，根据您发布的建议，我担心回归测试人员必须推断并找出要测试的案例。这是进行回归测试的一种可怕方式。每个案例都应该详细说明。即使它对你来说是 "obvious"，我保证它对其他人来说并不明显（反之亦然）。另外，即使对您自己来说，如果您必须进行回归测试，那么您也希望事情变得简单。压力越大的回归测试，它发生的可能性就越小，也就越不会做好。拥有明确的清单可以减轻压力并更容易遵循。行为驱动与回归测试完全一致。
我不明白当没有实际的业务操作来测试某些东西时，场景应该是什么样子。
下面的场景够好吗？不明白怎么转换成Past, Action, Future序列
Scenario:
Given The system contains the following users
| email | role |
| admin@example.com | ADMIN |
| user@example.com | USER |
And The system contains the following Products
| Name | Active |
| Product1 | true |
| Product2 | false |
Then The list of Products for 'admin@example.com' user should contain the following entries
| Name | Active |
| Product1 | true |
| Product2 | false |
And The list of Products for 'user@example.com' user should contain the following entries
| Name | Active |
| Product1 | true |
就个人而言，这就是我编写该场景的方式：
Scenario Outline: Viewing inactive products in different roles
Given I am logged in as <user_role>
And the system contains the active product "product1"
And the system contains the inactive product "product2"
When I view the available products
Then I should see the "product1" product
And I <should_see_inactive?> see the "product2" product
Examples:
| user_role | should_see_inactive? |
| an admin | should |
| a user | should not |
您似乎在此处测试的是角色中的特定用户是否具有查看非活动产品的正确访问级别。
您的陈述的编写方式似乎应该编写 2 个场景，并且当您为 2 个不同的用户组测试相同的内容以显示差异时，我正在使用 Scenario Outline
tl;博士
沟通困难。将 behavior（即 "when" 子句）嵌入到需求中更好（IMO）。
您发布的建议需要解释
您发布的建议实际上并没有告诉我要求是什么！相反，我现在必须弄清楚潜在的意图是什么才能得到你想要的东西。换句话说，我必须 "reverse engineer" 预期的逻辑。这是传达需求的一种更糟糕的方式。事实上，这是一种更糟糕的交流方式。
这是对您发布的建议的一种解释
Given a user who is not an admin
And products which are not active
When that user ever views any products
Then he cannot view the inactive products
Given a user who is an admin
And products which are not active
And products which are active
When that user ever views any products
Then he can view the both sets of products
但是，在您发布的建议中，是否应该允许非管理员查看 非活动产品？这是一个合理的问题。
如果你只说某些产品是"for"某某，那我不知道你是说"ownership"还是"viewability."如果我编写了允许所有用户查看其他人的产品的代码？如果您单击管理员用户配置文件，您会看到所有产品。如果您单击非管理员用户配置文件，您只会看到活动产品。看？我已经根据您的要求成功地为每个用户策划了列表。但是，如果您的意图是基于安全性的呢！不知何故，非管理员根本不应该看到 UI 中存在的那些产品。这是一个非常不同的要求，但您的文章并没有区分它。这是另一个很好的解释：如果你想让我过滤的唯一东西是某种 "selectibility" 怎么办？即：我可以查看所有产品，但我不能 select/attach/use 非活动产品（除非我是管理员）。同样，这是对策展和可见性的不同解释。
您可能会声称 "context" 使这一点显而易见。考虑到应用程序的页面流，没有人会误解其意图。然而，当你看到足够多的程序发生重大变化后，你会更看重 而不是 取决于 "context" 使事情变得 "obvious." 或者有人只是将你的小黄瓜文件拆分成什么两部分。如果周围的要求是正确解释这个的必要条件，那么现在我们通过改进代码中的文件结构就已经失去了它。
总之，沟通难。我相信将 行为 嵌入到需求中可以减少人们误解它的可能性。
为什么我更喜欢我的建议（其中有一个 "when" 子句）
相比之下，这个答案中的建议是字面意思。无论以后添加或更改了哪些其他权限层或数据库架构如何更改，我们都知道要求是什么。
我认为行为驱动的需求也可以帮助您更好地与产品负责人沟通。我敢打赌产品所有者会说 "I don't want anyone else (other than admins) being able to see inactive products." 我的建议几乎是产品所有者在那种情况下会说的。您的建议必须 "translate" 程序员喜欢思考的 "data-driven" 视图的真实意图。但是，我们 "translate" 将他们的注释转换成不同格式（如数据结构图）的次数越多我们冒着假设和误解的风险。这样的翻译 "lossy." 在我们的职业生涯中，我们听到产品所有者说 "what? That's not what I said!" 的次数越多，我们就越会对 "implicit" 沟通或 "obvious" 需求翻译感到不自在。相反，明确说明每一个文字要求。
根据我的经验，产品负责人总是首先考虑更多 behavior/customer-driven 个方面。不过这只是我的经验。
关于小黄瓜
Gherkin 只是一个工具，所以它只做一件事并且做好一件事：它迫使您思考 行为 驱动开发 (BDD)。如果您使用小黄瓜，则必须根据 "input" 行为及其所需的结果来编写内容。否则你用错了工具。
相反，您应该决定您是否认为 BDD 是一种强迫自己遵循的好哲学。如果您认为遵循该理念是好的，那么您将需要不断改写要求，直到出现 "when" 语句。一些人（包括我）认为强迫自己发表 "when" 声明的练习是好的。
此外，gherkin 与其他文档并不互斥。例如，您仍然会有 ERD 图、UI 模型等。事实上，您甚至可以从其他设计文档中引用小黄瓜场景。 Gherkin 旨在帮助您了解您是否按照客户的要求进行操作，而不是您是否将代码设计得很好。其他规范会这样做，并且它们可以协同工作。
不仅如此，"requirements" 本身也有层次，并以不同的媒介呈现。例如，您可能需要产品所有者为客户编写的 "sign-off" 文档。该文档的格式与小黄瓜 非常 不同，因此很好。在另一个极端，你有一个 ERD 图。我将小黄瓜视为 "in between" 需求抽象级别。
此外，回归测试应该变得简单。使用小黄瓜，您甚至可以将其自动化。然而，再一次，根据您发布的建议，我担心回归测试人员必须推断并找出要测试的案例。这是进行回归测试的一种可怕方式。每个案例都应该详细说明。即使它对你来说是 "obvious"，我保证它对其他人来说并不明显（反之亦然）。另外，即使对您自己来说，如果您必须进行回归测试，那么您也希望事情变得简单。压力越大的回归测试，它发生的可能性就越小，也就越不会做好。拥有明确的清单可以减轻压力并更容易遵循。行为驱动与回归测试完全一致。