我不明白当没有实际的商业行为来测试某些事情时，应该怎么样。
以下情况是否足够好？我不明白它如何转换成过去，行动，未来序列。
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 |
答案 0 :(得分：1)
沟通如果难以实现。将行为（即＆＃34;当＆＃34;子句）嵌入需求中更好（IMO）。
您发布的建议实际并没有告诉我要求是什么！相反，我现在必须弄清楚潜在的意图必须是什么才能获得你所追求的东西。换句话说，我必须＆＃34;逆向工程＆＃34;预期的逻辑。这是沟通需求的更糟糕方式。事实上，这是一种更糟糕的沟通方式。
以下是对您发布的建议的一种解释
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
但是，在您发布的建议中，是否应允许非管理员查看非活动产品？这是一个合理的问题。
如果您唯一说的是某些产品是＆＃34;对于＆＃34;某某，我不知道你的意思是＆＃34;所有权＆＃34;或者＆＃34;可见度。＆＃34;如果我编写的代码允许所有用户查看其他人的产品，该怎么办？如果单击管理员用户配置文件，则会看到所有产品。如果单击非管理员用户配置文件，则只能看到活动产品。看到？我已根据您的要求成功策划了每个用户的列表。但是如果你的意图是基于安全的呢！不知何故，非管理员根本不应该看到UI中存在的那些产品。这是一个非常不同的要求，但你的写作并没有区分它。这是另一个很好的解释：如果你想让我过滤的唯一一件事就是某种＆＃34;可选择性＆＃34 ;?即：我可以查看所有产品，但我无法选择/附加/使用非活动产品（除非我是管理员）。同样，这是对策展和可见性的不同解释。
您可能会声称＆＃34; context＆＃34;这很明显。鉴于应用程序的页面流量，没有人会误解意图。但是，在您看到足够的程序经历重大更改后，您将根据＆＃34; context＆＃34;来评估 not 。制造事物＆＃34;显而易见。＆＃34;或者有人只是将你的小黄瓜文件分成两部分。如果需要周围的要求来正确解释这个问题，那么现在我们只是通过改进代码中的文件结构而失去了它。
简而言之，沟通如果难以实现。我认为将行为嵌入到需求中会降低人们误解它的可能性。
相比之下，这个答案中的建议是字面的。在以后添加或更改其他权限层或者数据库架构如何更改并不重要，我们知道需求是什么。
我认为行为驱动的要求可以帮助您更好地与产品负责人沟通。我打赌产品所有者会说＆＃34;我不希望其他人（管理员除外）能够看到不活跃的产品。＆＃34;我的建议几乎是逐字逐句产品所有者在这种情况下会说的。你的建议必须＆＃34;翻译＆＃34;对数据驱动的真正意图＆＃34;看一个程序员喜欢思考。然而，我们越是翻译＆＃34;他们对不同格式（如数据结构图）的评论越多，我们就越有风险假设和误解。这样的翻译是有损的。＆＃34;在整个职业生涯中，我们听到我们的产品所有者说的是什么？这不是我所说的！＆＃34;我们越会感到不舒服＆＃34;隐含＆＃34;沟通或＆＃34;显而易见的＆＃34;翻译要求。相反，明确说明每个字面要求。
根据我的经验，产品所有者总是首先考虑更多行为/客户驱动的术语。这只是我的经历。
相反，您应该决定是否认为BDD是强迫自己遵循的好理念。如果你认为遵循这种哲学是好的，那么你需要不断重述这个要求，直到＆＃34;当＆＃34;声明。这种做法迫使自己制造一个＆＃34;当＆＃34;一些人（包括我）认为声明是好的。
此外，小黄瓜与其他文档并不相互排斥。例如，您仍然会有ERD图，UI模型等。事实上，您甚至可以在其他设计文档中引用小黄瓜场景。 Gherkin旨在帮助您了解您是否正在做客户要求的事情，而不是您是否正在设计代码。其他规格可以做到这一点，并且它们可以协同工作。
不仅如此，还有＆＃34;要求＆＃34;它们本身具有层次，并以不同的介质表示。例如，您可能需要＆＃34;签收＆＃34;产品所有者为客户撰写的文档。该文档的格式非常与小黄瓜不同，因此很好。在另一个极端，你有一个ERD图。我看到小黄瓜在＆＃34;之间＆＃34;那些需求抽象层次。
此外，回归测试应该很容易。使用小黄瓜，你甚至可以实现自动化。然而，再次，根据您发布的建议，我担心回归测试人员必须推断并找出要测试的案例。这是进行回归测试的一种可怕方式。每个案例都应该拼写出来。即使它很明显＆＃34;对你来说，我保证对别人来说并不明显（反之亦然）。另外，即使是你自己，如果你必须进行回归测试，那么你希望事情变得容易。回归测试压力越大，发生的可能性就越小，完成得越少。明确的清单使其压力更小，更容易理解。行为驱动与回归测试完全一致。
答案 1 :(得分：0)
就个人而言，这就是我写这种情况的方式：
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