cucumber - 在哪里正确提取 Cucumber 步骤数据？

Question

我需要编写一个类来强制执行关于可以或不可以添加到仓库中同一容器中的元素的规则，我想在实现之前将这些要求转换为 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

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

Answer 1

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

第 6 章来自 The Cucumber Book “When Cucumbers Go Bad”确实有助于引导到正确的细节级别。我真的认为你应该读一读，尤其是关于提出一种无处不在的语言的部分。我认为这将帮助您为您的组织确定合适的详细程度。

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

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