Cucumber多feature文件复用Background步骤的实现方案与最佳实践问询

结论先行 #

完全可以将重复的Background步骤统一抽取复用，目前主流BDD框架（Cucumber、Behave、SpecFlow等）都有成熟的实现方案，以下是几种常用的实践方式：

方案1：高阶步骤封装（通用性最强，无框架依赖） #

这是最推荐的通用方案，无需依赖框架特殊特性，所有BDD框架都支持：

• 把重复的4步前置逻辑封装为1个语义明确的复合步骤，比如命名为Given the default test site and user data is prepared
• 在对应步骤定义（Step Definition）中实现原有4步的全部逻辑
• 所有需要该前置的Feature的Background仅需写这1行即可

示例修改后的Feature文件：

Feature: Multiple site support

Background: 
  Given the default test site and user data is prepared

Scenario: Dr.Greg posts to his own blog
  Given I am logged in as Dr.Greg
  When I try to post to "Some" in my blog
  Then I should see "Some articles."

方案2：标签+钩子自动执行（简化度最高） #

如果你使用的是支持钩子（Hook）的BDD框架，可以进一步简化：

• 给所有需要该前置的Feature/Scenario打上自定义标签，比如@use_default_background
• 在全局的before_scenario钩子中增加判断逻辑：如果当前场景/所属Feature带有上述标签，就自动执行这4步前置逻辑
• 采用该方案后，Feature文件中甚至不需要写Background块，完全消除重复代码

方案3：外部Background片段导入（框架依赖） #

部分框架或第三方扩展支持导入外部Feature片段，你可以把公共Background单独存为common_background.feature文件，在需要的Feature中用对应导入语法引入即可。但该方案兼容性较差，不同框架的导入语法差异大，不如前两种方案通用。

行业实践注意事项 #

• 避免过度封装：如果部分Feature的前置逻辑存在细微差异，可将公共步骤拆分为更小的粒度，按需组合即可，不要为了复用强行合并差异逻辑
• 保证语义可读性：封装的高阶步骤名称要清晰说明其执行的操作，不要使用模糊命名，避免看Feature文件的人员无法理解前置准备的内容
• 测试数据可配置：公共步骤中用到的固定测试数据（比如用户名、博客名称）建议统一存放在配置文件中，不要硬编码在步骤定义里，后续修改时仅需调整配置即可

内容的提问来源于stack exchange，提问作者Tom