cucumber - 如何提高 SpecFlow/Gherkin 步骤之间的可重用性？

Question

我想我彻底理解了 SpecFlow 背后的概念和想法，但即使在阅读了Secret Ninja Cucumber Scrolls之后, The Cucumber Book ，并浏览了各个论坛，我仍然不确定可重用性的途径。

我们的场景已经符合各种准则

• 不言自明
• 必须有一个可以理解的目的(与其他场景有何不同)
• 独一无二
• 代表垂直功能切片
• 使用通用语言
• 从利益相关者的角度撰写
• 关于业务功能，而不是软件设计
• 按史诗分组
• 不是测试脚本
• 让其他人阅读它们，看看场景是否正确
• 不引用 UI 元素
• 代表关键示例
• 非技术
• 精确且可测试
• 尽可能可重复
• “Given”代表状态，而不是操作
• “何时”代表操作
• “然后”应该代表可见的变化，而不是某些内部事件

我们的步骤必须遵守以下准则(有些准则特定于 SpecFlow):

• 使用通用语言
• 不引用 UI 元素
• 不应合并
• 所有功能均应可重用且具有全局性
• 不应链接到特定功能
• 按实体、实体组或域概念分组
• 不要创建步骤来重用步骤定义文件中的逻辑
• 仔细考虑某个步骤属于哪个步骤文件
• 不要在阶段之间重复使用步骤
• 必须避免步骤中的文字字符串，但如果需要，请使用单引号
• 切勿将多个 [Given]、[When] 或 [Then] 属性应用于步骤 方法
• 根据步骤所代表的阶段对步骤进行排序
• 如果对于场景来说不重要，那么就不要提及它非常重要

但是即使我们使用正则表达式占位符，我们仍然会得到相同步骤的许多变体。尤其是“如果某件事不重要，就不应该提及”的规则会导致这些变化。是的，这些步骤在内部进行了大量的重用，但在场景中却没有。

例如，考虑以下场景:

Feature: Signing where both persons are physically available

@Smoke
Scenario: Show remaining time to sign based on previous signature
  Given a draft proposal
  And the first signature has been set
  When I try to set the second signature
  Then the remaining time to sign should be shown

@Smoke
Scenario: Re-signing of the first proposal
  Given a signature that has not been set within the configured time
  And the first signature has just been re-signed
  When I try to set the second signature
  Then the remaining time should start over

将两个“给定”步骤合并为一个并放弃一些可重用性会更好吗？

其他一些例子:

Feature: Conditionally show signatures to be signed

@Smoke
Scenario: Show the correct signature for a proposal with a night shift
  Given I have a proposal for the day shift
  When I change it to the night shift
  Then I should only be able to sign for the night shift

@Smoke
Scenario: Show additional signature when extending the shift
  Given I have a suspended proposal for the night shift
  When I extend the period to the day shift
  Then I should confirm extening the period over the shift

我在这里错过了一个基本概念吗？

Answer 1

这不是答案，而是一些提示:

• 您可以在同一个方法上放置多个 Give/When/Then 属性。如果参数相同并且差异仅在于措辞，这可能很有用
• 在许多项目中我们使用驱动程序/页面对象模式，因此步骤定义通常很短(2-3行)，因此我们不太关心它们的数量
• 我喜欢你的场景，我不会改变它们。另一方面，尝试关注可读性而不是可重用性。如果你的语言是一致的，那么可重用性就会到来。
• 为了提高可重用性，特别是当您正在谈论的实体有很多“变体”时，您可以考虑使用 step argument transformations 。这是一个例子:

您需要一个类来表示带有装饰的测试中的许可:

class PermitDescription{
  bool suspended;
  bool draft;
}

创建转换器方法:

[StepArgumentTransformation("permit")]
public PermitDescription CreateSimple(){
  return new PermitDescription();
}
[StepArgumentTransformation("draft permit")]
public PermitDescription CreateDraft(){
  return new PermitDescription() { draft = true; }
}
[StepArgumentTransformation("suspended permit")]
public PermitDescription CreateSuspended(){
  return new PermitDescription() { suspended = true; }
}

您现在可以拥有需要许可的更灵活的步骤定义:

[Given(@"I have a (.*) for the day shift")]
public void Something(PermitDescription p)
{ ... }

匹配到:

Given I have a permit for the day shift
Given I have a draft permit for the day shift
Given I have a suspended permit for the day shift

当然，这个工具也可能被滥用，但在某些情况下它可以提供帮助。