Question

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

每个项目都有多个属性，例如“项目系列”（例如：电子产品，书籍），“项目状态”（例如：主要库存，库存错误）和“批次”（例如：1050,1051）。 / p>

我可以想到为此编写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”在该场景/特征中的关键区别。在编写测试时，这也是首选。

一般来说，imho写黄瓜测试就像把自己放在岩石和坚硬的地方之间。我注意到开发人员倾向于重用并重复使用黄瓜步骤来创建难以理解和维护的场景。第二种方法需要更多的工作来定义步骤，但是场景更清晰，更容易阅读......但是它需要更多的时间来编写场景，并且它会产生大的步骤定义基础，这很难维护。

If you really want Cucumber for bdd然后我最倾向于第二选择。只需确保您使用FactoryGirl或类似的东西，创建通用对象并一次只覆盖您需要的内容。

我希望你觉得这很有用。

Answer 2

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

第3章来自The Cucumber Book“当黄瓜变坏时”对于指导正确的细节水平非常有帮助。我真的认为你应该给它一个阅读，特别是关于提出无所不在的语言的部分。我认为这将有助于您确定组织的正确级别。

如果您想尝试使用第一个测试，我的问题是，“您多久会改变一次这些值？”如果答案是“不是非常”或“从不”，那么您应该考虑它们是否会增加或减损测试的可读性。

P.S。我还在阅读The Cucumber Book，但到目前为止它一直非常有用，例如指出我对socjopata建议的FactoryGirl。

在哪里正确抽象黄瓜步骤数据？

2 个答案: