CQRS架构下Gherkin场景编写咨询：复用步骤与可读性权衡

这绝对是写Gherkin测试时最头疼的两难问题之一——既要省时间复用步骤，又要保证场景清晰可读，我太懂这种纠结了！结合你提到的费用管理业务场景，其实不用在两个方案里硬选，咱们可以用混合策略兼顾效率和可读性，下面给你具体拆解：

先明确核心测试目标 #

咱们的核心需求是验证「用户仅能给自己创建的费用包添加费用」，所有测试方案都要围绕这个业务规则展开，别为了复用步骤偏离核心。

方案优缺点拆解 #

先帮你理清楚两个方案的坑：

• 方案1（复用优先）：省开发时间是真的，但无关字段会让场景变得臃肿，比如场景里可能出现一些和权限验证完全无关的字段，新人看的时候会懵：“这些字段到底干嘛用的？”时间长了，维护成本反而会上升——你得不停解释哪些是关键参数，哪些是凑数的。
• 方案2（可读性优先）：场景确实清晰，一看就懂业务规则，但步骤无法复用意味着后期业务变更（比如权限逻辑调整）时，你要改N个重复的步骤绑定，反而浪费时间。

推荐的混合策略：复用基础步骤 + 具象业务场景 #

咱们可以把通用逻辑抽成可复用的基础步骤，然后用**场景大纲（Scenario Outline）**来写具象的业务场景，既省代码又清晰。

第一步：抽离通用可复用步骤 #

把和业务无关的基础操作抽成绑定步骤，比如「创建用户」「创建费用包」「尝试添加费用」「验证结果」，每个步骤只保留必要参数，别硬塞无关内容：

// 通用步骤绑定示例
[Given(@"用户 (\w+) 已创建费用包 (\d+)")]
public void GivenUserHasCreatedExpenseBundle(string username, int bundleId)
{
    // 复用的创建费用包逻辑：关联用户与费用包ID
}

[When(@"用户 (\w+) 尝试向费用包 (\d+) 添加费用")]
public void WhenUserTriesToAddExpenseToBundle(string username, int bundleId)
{
    // 复用的添加费用逻辑：调用CQRS的命令API
}

[Then(@"操作应该成功")]
public void ThenOperationShouldSucceed()
{
    // 验证命令执行成功、费用已添加
}

[Then(@"应该返回错误提示：(.+)")]
public void ThenShouldReturnError(string errorMessage)
{
    // 验证权限错误提示
}

第二步：写具象的业务场景（用Scenario Outline） #

用场景大纲覆盖所有测试边界，场景描述完全贴合业务语言，没有无关字段，同时底层调用复用的步骤：

Feature: 费用包添加费用权限验证
  作为费用管理系统用户
  我希望只能给自己创建的费用包添加费用
  以确保费用数据的归属安全

  Scenario Outline: 验证费用包添加权限规则
    Given 用户 <操作者> 已创建费用包 <自有费用包ID>
    And 用户 <其他用户> 已创建费用包 <他人费用包ID>
    When 用户 <操作者> 尝试向费用包 <目标费用包ID> 添加费用
    Then <预期结果>

    Examples:
      | 操作者 | 其他用户 | 自有费用包ID | 他人费用包ID | 目标费用包ID | 预期结果                     |
      | Alice  | Bob      | 1001         | 2001         | 1001         | 操作应该成功                 |
      | Alice  | Bob      | 1001         | 2001         | 2001         | 应该返回错误提示：无权限修改该费用包 |

这种方案的优势 #

1. 可读性拉满：非技术同事看Examples就能立刻明白业务规则，不用纠结无关字段
2. 复用性足够：所有基础步骤都是通用的，后续加其他权限场景（比如删除费用包）也能直接用
3. 维护成本低：如果权限逻辑变了（比如新增管理员权限），只需要修改对应的绑定代码，所有场景自动更新

额外的小建议 #

• 别为了复用而复用：如果某个步骤只能在特定场景用（比如“添加跨境费用”这种特殊场景），那就写具象步骤，别硬套通用模板，否则场景会变得晦涩
• 保持场景的业务导向：Gherkin的核心是“活文档”，场景描述要像自然语言一样说清楚业务规则，别写成技术操作步骤（比如别写“调用AddExpense命令”，要写“尝试向费用包添加费用”）
• 定期清理冗余：如果某个通用步骤半年都没被复用，就考虑改成具象步骤，减少不必要的维护负担

内容的提问来源于stack exchange，提问作者J. Vis