在哪里正确抽象 Cucumber 步骤数据？答案

【问题标题】：Where to abstract Cucumber step data properly?在哪里正确抽象 Cucumber 步骤数据？
【发布时间】：2012-04-16 09:33:33
【问题描述】：

我需要编写一个类来执行有关可能会或可能不会添加到仓库中的同一容器中的物品的规则，并且我想在实现之前将需求转换为 Cucumber。

每个商品都有多个属性，例如“商品系列”（例如：电子产品、书籍）、“商品状态”（例如：主要库存、故障库存）和“批次”（例如：1050、1051）。

我可以想到几种为此编写 Cucumber 测试的策略，我想知道推荐哪种策略：

首先，您可以列举每个产品的所有属性：

Given I have a tote containing:
  | sku    | client  | family  | status | batch | weight |
  | 100000 | Foo     | garment | main   | 1234  |     10 | 
When I add the item:
  | sku    | client  | family  | status | batch | weight |
  | 200000 | Bar     | garment | main   | 1234  |     10 |
Then I should be told there is a Client conflict

其次，您可以硬编码一个基本产品，并尝试指定与其不同的最小属性：

Given I have a tote containing an item that's client "Foo"
When I add an item that's client "Bar"
Then I should be told there is a Client conflict

这假定步骤定义包含基本属性，并在步骤中提到属性时覆盖它们。

最后，你可以进一步抽象：

Given I have a tote containing an item
And I add an item with a different client
Then I should be told there's a client conflict

这里有关于正确方法的指导吗？

【问题讨论】：

标签： cucumber bdd

【解决方案1】：

The Cucumber Book 的答案将是您团队中的非技术成员最容易阅读的答案。与 QA 负责人和项目经理坐下来，问他们同样的问题。我遇到了类似的问题，并从您的第一个建议开始。然后我觉得它太详细了，跳到了#3。然后我和项目经理坐下来，发现当我创建数据时我不需要任何细节，但是当我们更改数据时（在我们的例子中更新发票上的行项目值），我们想看看那些值在步骤中。

The Cucumber Book 的第 6 章“当 Cucumbers Go Bad 时”对于指导正确的细节水平非常有帮助。我真的认为你应该读一读，尤其是关于提出一种无处不在的语言的部分。我认为这将帮助您确定适合您的组织的详细程度。

如果您想使用第一个测试，我向您提出的问题是，“您打算多久更改一次这些值？”如果答案是“不太”或“从不”，那么您应该考虑它们是否会增加或降低测试的可读性。

附：我仍在阅读The Cucumber Book，但到目前为止它非常有帮助，例如按照 socjopata 的建议将我指向 FactoryGirl。

【讨论】：

【解决方案2】：

提到的第一个选项是最灵活和可重复使用的选项。使用第一种方法，您基本上可以涵盖您可能需要的任何情况，但也有一些缺点，您将在下面阅读。

第二个和第三个选项更容易阅读，这也是编写测试时的一个重要因素。此外，似乎专注于实际测试的内容，即“Foo”和“Bar”似乎在该场景/功能中产生的关键区别。这也是编写测试时的首选。

通常，恕我直言，编写 Cucumber 测试就像将自己置于岩石和坚硬的地方之间。我注意到开发人员倾向于重用和过度重用黄瓜步骤，从而创建难以理解和维护的场景。第二种方法需要在定义步骤方面做更多的工作，但场景更清晰、更易于阅读……但它需要更多的时间来编写场景，并且它会产生一个大的步骤定义库，这可能很难维护。

If you really want Cucumber for bdd 那么我会倾向于第二个选项。只需确保您在后台使用 FactoryGirl 或类似的东西来创建通用对象并一次只覆盖您需要的内容。

我希望你觉得这很有用。

【讨论】：