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

Question

我需要编写一个类来强制执行关于物品的规则，这些物品可以添加到仓库中的同一个容器中，也可以不添加到仓库中的同一个容器中，我想在实现之前将这些要求转化为Cucumber。

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

我可以想出几种写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

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

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

一般来说，写cucumber测试就像把自己置身于岩石和坚硬的地方之间。我注意到，开发人员倾向于重用和过度重用这些步骤，从而创建难以理解和维护的场景。第二种方法需要在定义步骤方面做更多工作，但场景更清晰，更容易阅读。。。但它需要更多的时间来编写场景，并生成一个大的步骤定义库，这可能很难维护。

如果你真的想要cucumber作为bdd，那么我会倾向于第二种选择。只需确保在引擎盖下使用FactoryGirl或类似的工具，创建通用对象并一次只覆盖您需要的内容。

我希望你觉得这很有用。

Answer 2

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

cucumber书中的第6章“当cucumber变坏时”对指导正确的细节非常有帮助。我真的认为你应该读一读，尤其是关于创造一种无处不在的语言的部分。我认为这将有助于您为您的组织确定正确的细节级别。

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

P. S.我还在读《cucumber书》，但到目前为止，它非常有帮助，例如像索科帕塔建议的那样，把我引向工厂女孩。