如何提高SpecFlow / Gherkin步骤之间的可重用性？ [英] How to increase reusability between SpecFlow/Gherkin steps?

问题描述

我认为我彻底了解SpecFlow背后的概念和想法，但即使在阅读了秘密忍者黄瓜卷轴， a href =http://pragprog.com/book/hwcuc/the-cucumber-book =noreferrer>黄瓜书，并通过各种论坛我仍然不确定的路径

• 自我解释
  
  
  


• 必须具有可理解的目的（与其他方案不同）


• 是独一无二的


• 垂直功能切片


• 使用无处不在的语言


• 从利益相关者角度编写


• 关于业务功能，软件设计


• 由Epics分组


• 不是测试脚本


• 让其他人阅读


• 不会引用UI元素


• 代表关键示例


• 非技术


• 精确且可测试


• 尽可能重复


• li>
  
• '何时表示动作


• Then应表示可见的更改，而不是某些内部事件

我们的步骤必须符合以下准则（一些是特定于SpecFlow）：

• 使用无处不在的语言


• 不引用UI元素


• 不应组合




• 根据实体，实体群组或网域概念进行分组


• 不要在步骤定义文件中创建重复使用逻辑的步骤


• 仔细考虑步骤所属的步骤文件




• 必须避免步骤中的文字字符串，但必要时使用单引号


• 不要应用多个[Given] When]或[Then]属性到步骤
  方法


• 根据它们代表的阶段对步骤排序


• 如果不是




但是我们还是有很多变化的同样的步骤，即使我们使用正则表达式占位符。特别是如果某事不重要，你不应该提到它导致这些变化的规则。是的，内部这些步骤做了很多重用，但不是在场景中。





请考虑以下情况：

 功能：签署两个人都可用的地方
 
 @Smoke 
场景：根据以前的签名显示剩余时间签名
提交草案
第一个签名已设置
当我尝试设置第二个签名
然后剩余的签名时间应该显示
 
 @Smoke 
方案：重新签名的第一个提议
给定一个在配置的时间内未设置的签名
第一个签名刚刚重新签名
当我尝试设置第二个签名
然后剩余的时间应该从
开始 

最好将两个给定并松动一些可重用性？





其他一些示例：

 特征：有条件地显示要签名的签名
 
 @Smoke 
情景：为具有夜班的提案显示正确的签名
假设我有一个日期提案$ b当我把它改为夜班
然后我应该只能签署夜班
 
 @Smoke 
场景：当延长shift $时显示额外的签名b $ b考虑到我暂停的夜班建议
当我将期限延长到一天班
然后我应该确认延长班期
  
解决方案
 
 p>这不是一个答案，但有一些提示：
 
 
 
 
 
你可以把多个Given / When / Then属性放在同一个方法上。如果参数是相同的，并且区别只在于短语，这在我们使用驱动程序/页面对象模式的许多项目中可以是有用的
 
 
，所以步骤定义通常很短-3行），所以我们更少关心它们的数量
 
 
我喜欢你的场景，我不会改变它们。另一方面，尝试关注可读性，而不是可重用性。如果你的语言是一致的，可重用性就会来了。
 
 
为了增加可重用性，特别是当你正在谈论的实体有很多变体时，你可以考虑使用< a href =https://github.com/techtalk/SpecFlow/wiki/Step-Argument-Conversions =noreferrer>步骤参数变换。以下是一个示例：
 
 
 
 
 
您需要一个类来表示在装饰测试中的许可：
  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; } 
} 
  
您现在可以有更灵活的步骤定义，需要许可证：
  [给定（@我有一个（。*）的日班）] 
 public void Something（PermitDescription p ）
 {...} 
  
 b 
 
 因为我有一个日班的许可证
考虑到我有一个日班的许可证草稿
考虑到我有暂停许可证对于日移
  
当然这是一个可以被滥用的工具，但在某些情况下帮助。
 
I think I thoroughly understand the concepts and ideas behind SpecFlow, but even after reading the Secret Ninja Cucumber Scrolls, The Cucumber Book, and going through the various forums I'm still unsure about the path to reusability.

Our scenarios already comply to various guidelines 


Self explanatory
Must have a understandable purpose (what makes it different from the other scenarios)
Are unique
Represent vertical functional slices
Uses Ubiquitous Language 
Written from the stakeholder perspective
About business functionality, not about software design
Grouped by Epics
ARE NOT TEST SCRIPTS
Let somebody else read them to see if the scenario is correct
Doesn't refer to UI elements
Represent key examples
Non-technical
Precise and testable
As repeatable as possible
'Given' represent state, not actions
'When' represent actions
'Then' should represent a visible change, not some internal event


Our steps have to comply to the following guidelines (some are specific to SpecFlow):


Uses Ubiquitous Language 
Doesn't refer to UI elements
Should not be combined
Should be reusable and global over all features
Should not be linked to a specific feature
Grouped by entities, entity groups or domain concepts
Don't create steps to reuse logic in a step definitions file 
Think thoroughly in what Steps file a step belongs
Don't reuse steps between phases
Literal strings in steps must be avoided, but if required use single quotes
Never apply multiple [Given], [When] or [Then] attributes to the step
method
Order the steps according to the phase they represent
If it is not important for the scenario, it is very important not to mention it


But we still end up with lots of variations of the same steps, even if we use regex placeholders. Especially the rule that if something is not important, you shouldn't mention it results in those variations. And yes, internally these steps do a lot of reusing, but not in the scenario. 

Consider for example the following scenario: 
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
Would it be better to combine the two 'given' steps into one and loose some reusability? 

Some other examples:
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
Am I missing a fundamental concept here?
解决方案
This is not an answer, but some hints:


you can put multiple Given/When/Then attributes on the same method. If the parameters are the same and the difference is only in phrasing, this can be useful
in many project we use driver/page object pattern, so the step definitions are usually quite short (2-3 lines), so we bother less about the number of them
I like your scenarios, I would not change them. On the other hand try to focus on the readability and not the reusability. If your language is consistent, the reusability will come.
For increasing the reusability especially when there are a lot of "variations" of the entity you are talking about, you can consider using the step argument transformations. Here is an example:


you need a class to represent a permit in the tests with decorations:
class PermitDescription{
  bool suspended;
  bool draft;
}
create converter methods:
[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; }
}
you can have now more flexible step definitions that require permits:
[Given(@"I have a (.*) for the day shift")]
public void Something(PermitDescription p)
{ ... }
that matches to:
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
of course this is tool that can be also abused, but in some cases it can help.

                        
这篇关于如何提高SpecFlow / Gherkin步骤之间的可重用性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！